[gaborbernat]

minify_css kept growing its own output when a stylesheet ended inside a function whose arguments held an open [ or { block with a ) inside, such as r{r:l([[)}, or inside an invalid unicode-range value (#1633). Every pass appended another }, so pipelines that minify already-minified CSS, and cache keys built from the result, never settled. Such input now minifies to the same text on every pass. 🔁

The minifier read nesting three ways: the declaration reader let any closer end the innermost block, function matching looked only at parentheses, and the end-of-input repair matched closers to their own kind. Each of them now reads blocks as CSS Syntax 3 §5.4.7 does, the same reading turbohtml's CSSOM and tinycss2 use: a block ends only at its own closer, and any other closer inside it is a plain value. The closers written at the end of the input therefore match what the next pass reads. The invalid unicode-range fallback, which copied the value verbatim, now gets those closers as well.

Behavior changes

• A stray closer inside an open block no longer ends that block. r{r:l([[)} now minifies to r{r:l([[)}]])} rather than r{r:l([[)}}, and @x ({)) keeps its )) inside the { and gains }).
• An @media rule whose only content is a block that swallows the rest of the input now minifies to nothing, as an empty @media does elsewhere.

Closes #1633

[codspeed]

Merging this PR will not alter performance

✅ 582 untouched benchmarks
⏩ 32 skipped benchmarks¹

---

_{Comparing fix/css-unclosed-function-block (2c8cf03) with main (7eef0dd)}

Footnotes

1. 32 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩