How to get CSS architecture right
The gap between knowing this and actually doing it is where most teams lose ground. The short answer to CSS architecture is that it is mostly a sequence of small decisions, not one big one.
Most development decisions are really maintenance decisions wearing a different hat. It rarely shows up as a line item, which is exactly why it slips.
Why it matters
Naming conventions prevent the specificity arms race. That sounds obvious written down. It is still the thing most often skipped. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.
The steps
- Establish what you have today before changing anything
- Custom properties centralise the values you change most
- Deleting CSS should be as easy as adding it
- Write down the decision so the next person does not re-litigate it
Deleting CSS should be as easy as adding it. In practice this is a scheduling problem more than a technical one. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.
A reasonable first step
The short version
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
- Deleting CSS should be as easy as adding it — and you know whether that is true here
- There is a way to tell whether the last change to this helped
If any of that sounds like a description of your current setup, it is fixable.