CSS architecture: organizing a real stylesheet at scale

Every part so far has added real rules to what's implicitly become one growing stylesheet. This part covers how to organize that real file (or split it into several) so it stays maintainable well past the point where a single flat list of rules starts becoming genuinely hard to navigate.

A real, practical file structure

styles/
├── tokens.css        → part 5's real custom properties (colors, spacing, type)
├── reset.css         → box-sizing, margin resets, real baseline normalization
├── base.css          → real, unclassed element styles (body, headings, links)
├── layout.css        → part 9-13's real header, grid, positioning rules
├── components/
│   ├── product-card.css
│   ├── forms.css
│   └── buttons.css
└── main.css           → imports every file above, in a real, deliberate order

/* main.css */
@import url("tokens.css");
@import url("reset.css");
@import url("base.css");
@import url("layout.css");
@import url("components/product-card.css");
@import url("components/forms.css");
@import url("components/buttons.css");

This real order isn't arbitrary — tokens have to load before anything that references them with var(); the reset and base layers establish real, foundational defaults before more specific component rules override them; component files come last, since they're generally the most specific, targeted rules in the whole real stylesheet.

Avoiding real specificity wars

/* the real trap: escalating specificity to win a conflict */
.product-card .price { color: #555; }
.sale .product-card .price { color: red; }
#homepage .sale .product-card .price { color: red !important; }

The real, better alternative: flat, class-based selectors with a
  deliberate naming convention, avoiding deep nesting entirely
.price { color: #555; }
.price--sale { color: red; }

This directly extends part 3's specificity coverage into a real, practical architectural principle: deeply nested selectors chasing a real specificity fight are a genuine, common sign the underlying approach needs rethinking, not more nesting. A flat, single-class-per-rule approach (part 2's .price--sale modifier pattern) sidesteps the entire real problem — every selector has roughly equal, low specificity, so later rules in the cascade reliably win through source order alone, exactly the predictable behavior part 3 covered as the simpler, real case.

When BEM (or a similar convention) genuinely pays off

.product-card { }
.product-card__title { }
.product-card__price { }
.product-card--featured { }
.product-card--out-of-stock { }

Introduced briefly in part 2, BEM's real value compounds specifically as a stylesheet grows — a class name like .product-card__price is immediately, unambiguously scoped to its real component, with zero risk of accidentally colliding with an unrelated .price class defined for something else entirely elsewhere in a large real stylesheet. For Bright Leaf Coffee's site at this series' current real scale, it's a genuinely optional nicety; for a larger real site with dozens of components built by more than one person, it becomes a genuinely load-bearing convention that prevents real, hard-to-trace naming collisions.

Real comments that explain why, not what

/* wrong: restates what the code already says */
.product-card {
  display: flex; /* makes it flex */
}

/* correct: explains a real, non-obvious reason */
.product-card {
  /* min-height keeps cards visually aligned even when one product's
     title wraps to two lines and another's doesn't */
  min-height: 320px;
}

A real, well-chosen comment explains a genuine constraint or decision that isn't obvious from the code alone — a comment restating what a property already says in plain English adds real, ongoing maintenance cost (it has to be kept in sync with the code) with zero real informational benefit.

A real, honest measure of good architecture

The genuine, practical test: can a real change to one component's
  styling be made confidently, without needing to check whether it
  will unexpectedly affect something unrelated elsewhere on the page?

Every principle in this part — token-based values, flat specificity, clear naming, purposeful file organization — serves this one real, practical goal. A stylesheet that passes this test reliably is genuinely well-architected, regardless of which specific convention or file structure was used to get there.

Next: common CSS mistakes — a direct, honest roundup of the real failure patterns this series has flagged individually, brought together in one place.