Layers
Control precedence before increasing specificity.
Decision trees
CSS architecture decision trees
Use these when CSS arguments start, code reviews lose clarity, or someone reaches for !important before asking where the code belongs.
Ask this first
Stop adding specificity first.
Ask: Am I changing behaviour, presentation, structure, or temporary state? That answer decides the destination before writing CSS.
Most bad CSS starts with the wrong destination, not the wrong selector. Decide ownership first.
Utility or component?
Does this solve a universal accessibility problem?
Yes → Utility
No ↓
Does this same pattern repeat together often?
Yes → Component
No ↓
Is it only a small one-off visual adjustment?
Yes → Theme
No ↓
If you need to explain it twice,
it probably needs a componentModifier or state?
Is this a permanent reusable variation?
Yes → Modifier
No ↓
Is this temporary, conditional, or JS-driven?
Yes → State class
No ↓
If it disappears when the user leaves,
it is probably stateBase vs theme vs component
Should this apply globally across the whole site?
Yes → Base
No ↓
Is this only visual presentation?
Yes → Theme
No ↓
Is this specific to one UI pattern?
Yes → Component
No ↓
You are probably writing a hackHack or real fix?
Is this urgent and temporary?
Yes → Hacks layer
No ↓
Will this still exist in 6 months?
Yes → Real fix
No ↓
If it feels permanent,
stop calling it temporaryLayout problem or component problem?
Is the issue about page structure and positioning?
Yes → Layout
No ↓
Is it specific to one reusable UI pattern?
Yes → Component
No ↓
If three components share it,
it is probably layout@scope, BEM, or neither?
Do you need native selector boundaries?
Yes → @scope
No ↓
Do you need explicit naming for legacy teams?
Yes → BEM may help
No ↓
Use semantic ownership and shallow selectors