Three myths about CSS architecture

It is rarely the thing that gets a project approved, and often the thing that decides how it goes. A few things about CSS architecture that get repeated more often than they get checked.

Code gets read far more often than it gets written, and usually by someone with less context than the author had. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

“It only matters for big sites”

Naming conventions prevent the specificity arms race. This is the sort of thing that compounds, quietly, in both directions. Doing this properly once is usually cheaper than doing it approximately three times.

“We can deal with it after launch”

Sometimes true, usually expensive. That sounds obvious written down. It is still the thing most often skipped.

“Our platform handles it”

Deleting CSS should be as easy as adding it. The reasoning matters more than the rule, because the rule has exceptions. Doing this properly once is usually cheaper than doing it approximately three times.

What this looks like day to day

The question is rarely whether something can be built, but what it costs to keep running afterwards. Three things worth confirming about CSS architecture before you move on:

• Someone can say what the current setup is without going to look
• Custom properties centralise the values you change most — and you know whether that is true here
• There is a way to tell whether the last change to this helped

The point is not perfection, it is knowing which of these you have consciously chosen to skip.