Decision trees
Turn principles into repeatable day-to-day decisions.
Learn
The non-negotiables
These are the rules underneath everything else. If these stay true, the system stays healthy. If these drift, the architecture quietly becomes archaeology.
Ask this first
Ask first: Does this make the system calmer, or only make this ticket disappear?
Good CSS reduces future decisions. Bad CSS creates new ones.
Most architectural damage starts when short-term speed defeats long-term ownership. The first question should always be where this belongs.
Ownership before selectors
Decide whether something belongs in settings, base, utilities, layout, components, theme, legacy, thirdparty (low layers), or hacks before writing selectors. Wrong ownership creates most bad CSS long before specificity joins the argument.
Layers before specificity
If styles are fighting, check layer order first. Do not reach for deeper selectors, IDs, or important declarations before checking precedence. Most specificity problems are architecture problems.
Prefer shallow selectors
Components should use short, scoped selectors with obvious ownership. Deep selectors couple styling to markup structure and turn safe changes into archaeological digs.
Utilities are exceptions, not architecture
Utility-first CSS in HTML—spacing, layout, and colour as class stacks on every element—is not what LSCSS means by utilities. That pattern is not semantic, it bloats markup, and it does not maintain well.
The utilities layer is for rare CSS helpers: accessibility patterns such as .vh and .a11y-link, not a second design system in templates. If combinations keep repeating, they are a component asking to be named.
Hacks are temporary by definition
The hacks layer exists for urgent delivery needs, not permanent residency. If a fix will still exist in six months, it is probably a real architectural problem pretending to be temporary.
Tokens before values
Spacing, colour, typography, and radius should come from tokens, not deadline-driven invention. Random values create design inconsistency, not maintainable systems.
Calm CSS beats clever CSS
Good CSS should feel boring. Predictable selectors, clear naming, obvious ownership, and fewer surprises matter more than cleverness. Future developers should not need detective work to ship safely.