Formatting is a debugging aid
Readable line breaks and indentation reveal selector boundaries, declaration blocks and missing closing braces. Formatting should preserve token meaning rather than reorder declarations or combine rules that may depend on the cascade.
When diagnosing generated CSS, keep the original asset and compare the rendered page after formatting. A readable result is not proof that invalid or unsupported declarations became valid.
Minify conservatively
Whitespace and comments are often removable, but CSS contains strings, escaped identifiers, custom properties and data URLs where simple regular-expression rewrites can be risky. The XXF tool intentionally avoids aggressive value rewriting and selector merging.
- Keep the authored source under version control
- Minify a build artifact, not the only copy
- Test data URLs and custom properties
- Use source maps in production debugging workflows
Use a parser for production optimization
A parser-based tool understands CSS tokens and is better suited to merging rules, shortening values, removing unreachable code or handling new syntax. Run the project's browser tests after changing optimizer versions because valid transformations can still expose cascade assumptions.
Color conversion does not measure contrast
HEX, RGB and HSL are representations of color values, not accessibility scores. Rounding during conversion can slightly change numeric values, and acceptable text contrast depends on the foreground-background pair, font size and weight.
Use the converter to normalize design tokens, then evaluate contrast in the final component state, including hover, disabled and dark-mode combinations.
Start with a simple declaration block
Use CSS Formatter / Minifier in the minify direction with this simple rule. The output removes optional spaces and the final semicolon without merging selectors or rewriting values. Compare it in the actual component before replacing a served stylesheet.
This fixture deliberately contains no strings, data URLs or calc expressions. XXF's current implementation uses regular-expression transformations, not a full CSS parser. It is suitable for inspecting simple snippets, but must not be treated as a semantics-preserving production optimizer for arbitrary stylesheets.
.card { display: grid; gap: 1rem; }.card{display:grid;gap:1rem}.label::before { content: "a > b"; }Check tokens whose whitespace is data
In the counterexample, a greater-than character is inside a quoted string. The current minifier can remove the surrounding spaces and change the displayed text to a>b. Strings, custom properties and embedded data can contain punctuation that looks like stylesheet structure to a regular expression.
Keep the authored CSS, use a parser-based build tool for production optimization and test computed styles and rendered states. Reversible formatting is still worth checking: adding line breaks inside a string can alter or invalidate its value. A smaller file is useful only when the browser interprets it as intended.
- Use this tool for simple snippets
- Preserve the source before transformation
- Check quoted text, data URLs and custom properties
- Use a CSS parser and browser checks for production builds
Read the specification
Put the guide into practice
Open the related browser tools and test the workflow with a synthetic sample