DEV Community

Michael Lip
Michael Lip

Posted on • Originally published at zovo.one

Why Auto-Formatting Your CSS Catches Bugs You Did Not Know You Had

#webdev #beginners #programming #css

Inconsistent CSS formatting is not just an aesthetic problem. It hides bugs. Missing semicolons, unclosed brackets, duplicate properties, and specificity conflicts all become harder to spot in messy code. I have tracked down more CSS bugs by reformatting the file first than I care to admit.

What proper CSS formatting looks like

There is no single standard, but the widely adopted conventions are:

  • One selector per line for multi-selector rules
  • Opening brace on the same line as the selector
  • Each property on its own line, indented
  • Space after the colon
  • Semicolon after every value (including the last one)
  • Closing brace on its own line
  • One blank line between rule sets 
.header,
.header-alt {
  display: flex;
  align-items: center;
  padding: 16px 24px;
  background-color: #12121a;
}

.navigation {
  margin-left: auto;
}
Enter fullscreen mode Exit fullscreen mode

Versus the mess that accumulates in production:

.header, .header-alt{display:flex;align-items:center;
  padding: 16px 24px;background-color: #12121a;}
.navigation {margin-left: auto}
Enter fullscreen mode Exit fullscreen mode

The second version has the same CSS but hides the missing semicolon after auto, makes the multi-selector rule harder to read, and obscures the property list.

Formatting reveals problems

When I reformat a large CSS file, I consistently find:

Duplicate properties: The same property declared twice in one rule, sometimes with different values. The second one wins. In a compressed or messy file, this is invisible. In a formatted file, you see both declarations stacked.

Vendor prefix ordering issues: Vendor prefixes should come before the standard property so the standard takes precedence if supported. Formatting makes the order visible.

Specificity accidents: Long, overly-specific selectors become obvious when each selector is on its own line. .page .content .section .card .title is clearly too specific, but compressed into one line among many, it blends in.

Orphaned rules: Selectors that no longer match any HTML but were never removed. In a well-formatted file, scanning section by section makes these easier to identify.

Minified CSS and debugging

Production CSS is usually minified -- all whitespace removed, everything on one line. This is correct for performance but terrible for debugging. When your browser's DevTools points you to line 1, column 14,392 of a minified CSS file, you need to format it before you can read it.

Source maps solve this in development, but when debugging production issues or analyzing third-party CSS, you need a formatter.

Property ordering

Some teams enforce a specific property order within rules. The two common approaches:

Grouped by type: Layout properties first (display, position, flex, grid), then box model (margin, padding, width, height), then typography (font, color, text), then visual (background, border, shadow), then animation.

Alphabetical: Simply alphabetize all properties. Easier to enforce, easier to find a specific property, but groups unrelated properties together.

Either approach is better than no order. The consistency makes it faster to scan rules and notice when something is out of place.

The formatter

For quick formatting of CSS snippets or full files, I built a CSS formatter that reformats with consistent indentation, spacing, and structure. Paste in minified or messy CSS, get clean, readable output.

I'm Michael Lip. I build free developer tools at zovo.one. 500+ tools, all private, all free.

Top comments (0)