CSSV: Comma-Separated Styled Values

I gave life to the old CSV files.

CSV is over 50 years old, and it's everywhere. Banks, CRMs, Jira, Google Calendar, gradebooks and ticketing systems all export it, and every tool reads it. And every time you open one, you get the same grey grid of raw values.

The data is fine. What's missing is the look. The moment you add one in Excel or Google Sheets, you lose what made CSV great: a plain-text file you can read, compare, generate and send anywhere.

So I built CSSV: Comma-Separated Styled Values. It's a CSV file with a CSS block on top. Open it in a browser and you get a real HTML table with your fonts and your custom styling. Delete the CSS and it's a plain CSV again.

There's nothing new to learn. The data is CSV and the look is CSS, two languages that people, programs and AI models already write. Any CSV is already a valid CSSV file. Add a few lines of CSS to a Jira export and it becomes a board, one lane per status. A ticketing export prints as name badges.

The look travels with the data. A file looks the same on every page that shows it. Many files can share one stylesheet, so changing it restyles all of them. It's still plain text. You can review it in a pull request, generate it from a script, or ask an AI to write one.

Putting it on a page takes one script tag and . No build step, no dependencies.

The v1 spec is open for review, and I'd love feedback, especially from anyone who spends their days looking at exports.

Website, examples and live editor: https://cssv.dev

Comments

[Launch Gate]

How does the v1 parser distinguish the optional CSS block from ordinary CSV data? I'd include a plain CSV fixture whose first quoted cell contains CSS-looking text, braces and a newline, then check that "any CSV is valid CSSV" doesn't accidentally reinterpret that cell as styling.

A paired round-trip check could strip the style block and compare the parsed rows with the original, including quoted commas, embedded newlines and empty trailing cells. That would give the plain-text compatibility claim a concrete boundary. I haven't tried the editor or read the full spec; these are parser fixtures suggested by the format described here.

[Rodrigo Paiva]

Good fixtures, thanks. The split happens before any CSV parsing. A file has a style block only if its first line is exactly --- (§3.4), and the block ends at the next such line. So a quoted first cell can't start one, whatever it contains.

I ran both against the parser. A first cell holding td { color: red }, a --- line and a } stays one data field. And the same CSV with and without a style block parses to identical rows, with quoted commas, embedded newlines, escaped quotes and empty trailing cells.

Your fixtures also point at the real boundary, and it's my wording, not the parser: "any CSV" should be "almost any". A CSV whose first line is exactly --- reads as an opening fence. That's why the spec says "most CSV files".