Layers
Use explicit cascade layers to control precedence and stop specificity wars before they begin.
Core methodology
Core methodology
LSCSS is not a naming trick. It is a full operating model for CSS: layers, ownership, predictable overrides, safe defaults, and rules that keep small shortcuts from becoming long-term maintenance debt.
Ask this first
Before writing CSS, decide what you are protecting.
- Are you protecting override order?
- Are you protecting ownership and readability?
- Are you protecting accessibility and performance?
- Are you protecting maintainability for the next developer?
- Or are you solving only today while increasing future cost?
Good methodology is not about stricter rules. It is about making the safe choice easier than the quick mistake.
Methodology sections
These are connected rules, not isolated preferences. Good CSS comes from the system working together, not from one clever selector.
Base styles
Keep resets, typography, and true global styles in the correct base layer.
Naming
Use semantic component names, short child classes, modifiers, and state classes.
Modifiers and state
Separate reusable variants from temporary or conditional UI state.
Architecture
Structure files, folders, responsibilities, and media queries predictably.
Utilities
Use utilities deliberately, not as a replacement for component architecture.
Theme layer
Keep visual overrides and brand styling separate from component logic.
Hacks
Contain temporary fixes so they do not become permanent architecture.
What this protects
- Layers protect override order and reduce specificity fights.
- Base styles protect global consistency and sensible defaults.
- Tokens protect spacing, colour, and typography consistency.
- Custom media protects breakpoint clarity and removes magic numbers.
- Scoped selectors protect ownership and readability.
- Modifiers and state protect intent and UI behaviour clarity.
- Legacy and hacks layers protect maintainability during change.
- File-size guidance protects cognitive load and code review quality.
None of these rules are complicated alone. Together they make CSS easier to explain, safer to change, and much harder to quietly ruin.
Where to start
Start with layers
Control precedence first. Most CSS problems begin when override order is accidental.
Use decision trees
When a CSS choice stops being obvious, use rules instead of instinct.
Use the starter structure
Begin with predictable architecture before `site.css` becomes hard to reason about.
The goal is not perfect CSS. The goal is CSS people can trust six months later without extra debugging effort.