CSS formatter that leaves the cascade alone

It cannot, because nothing is reordered and nothing is combined. A stylesheet is an ordered list where the last equally specific declaration wins, so a tool that sorts your properties alphabetically or merges two rules with the same selector is editing the cascade even when the output looks tidier. Here the rules come out in the order they went in, duplicates stay duplicated, shorthand and longhand keep their relative positions, and no selector is rewritten — the only characters that move are whitespace, plus the line breaks that put each declaration on its own line.

Each one opens a block that indents its contents one level, to whatever depth the sheet actually goes — a real build here nests four deep without complaint. The prelude gets a space after the colon inside its parentheses, so (min-width:48rem) becomes (min-width: 48rem), and that spacing is applied only inside parentheses on purpose: @page :first has a colon that starts a pseudo-class and must not be touched. Statement at-rules that end in a semicolon rather than a block — @charset, @import, @layer base, components — stay on one line.

Yes: a nested rule is a rule, and it is indented under its parent like any other block. That is now the common case rather than an exotic one, since nesting shipped in every major browser and Tailwind-style builds emit it freely. Ampersand selectors, nested at-rules inside a rule, and rules nested inside those are all laid out by depth. The depth counter under the tool tells you how far down the sheet goes, which is a useful smell test on a file you have inherited.

Mostly, with one specific gap: // comments. Variables like $brand, at-rules like @mixin and @include, and nesting all survive perfectly well, because they fit the same block-and-declaration shape the reader already follows. But a double-slash comment is not CSS syntax at all, and the reader treats the rest of that line as part of whatever comes next — so a // note above a selector ends up glued to it. Convert those to /* … */ first, or expect to tidy them afterwards.

Because a custom property does not hold a CSS value, it holds an arbitrary run of tokens that something else will substitute later. --gutter: 0px 16px might be read by a calc() somewhere, pulled apart by JavaScript, or fed to a property that needs the unit spelled out; --shadow: 0 0 0 1px red is not the tool's business to re-space. Everything after the colon is copied out unchanged. Ordinary declarations do get normalised: one space after the colon, one space after a comma, and the value collapsed to single spaces.

Comments are all kept, and where they sit is kept too: one written above a declaration stays above it, one written after it stays on that line's end. Strings are the more interesting case, because CSS values can contain characters that look structural. content: "} not a brace" does not end the rule, a font stack like "Foo, Bar", sans-serif keeps the comma inside the quoted name, and an unquoted url() holding a base64 data URI is copied out whole rather than having its commas and semicolons respaced.

Five things, and each one names itself: a string that never closes, a /* comment that never closes, a url() that never closes, a } with no matching {, and a file that ends inside an open block. In all five the original text comes back untouched with the reason underneath. That is deliberate — once the brace nesting is ambiguous there is no honest way to say which rule a declaration belongs to, and guessing would move a property into the wrong selector, which is far worse than a stylesheet that stayed ugly.