Layers
Control precedence before increasing specificity.
Apply
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?
YesUtility
NoNext question
Does this same pattern repeat together often?
YesComponent
NoNext question
Is it only a small one-off visual adjustment?
YesTheme
No
If you need to explain it twice, it probably needs a component
Modifier or state?
Is this a permanent reusable variation?
YesModifier
NoNext question
Is this temporary, conditional, or JS-driven?
YesState class
No
If it disappears when the user leaves, it is probably state
Base vs theme vs component
Should this apply globally across the whole site?
YesBase
NoNext question
Is this only visual presentation?
YesTheme
NoNext question
Is this specific to one UI pattern?
YesComponent
No
You are probably writing a hack
Hack or real fix?
Is this urgent and temporary?
YesHacks layer
NoNext question
Will this still exist in 6 months?
YesReal fix
No
If it feels permanent, stop calling it temporary
Layout problem or component problem?
Is the issue about page structure and positioning?
YesLayout
NoNext question
Is it specific to one reusable UI pattern?
YesComponent
No
If three components share it, it is probably layout
@scope, BEM, or neither?
Do you need native selector boundaries?
Yes@scope
NoNext question
Do you need explicit naming for legacy teams?
YesBEM may help
No
Use semantic ownership and shallow selectors