CSS Architecture Overview
CSS has no built-in module system, no enforced scoping, and every rule you write competes globally with every other rule on the page. On a small project this doesn't matter. On a large one — dozens of contributors, hundreds of components, years of iteration — it becomes a genuine problem: class names collide, specificity creeps upward as people reach for more specific selectors or
!important to win the cascade, and nobody can delete an old rule with confidence because nothing tells them what still depends on it. CSS architecture methodologies exist to prevent that slow decay by giving a team shared rules for how to name things, where things live, and how specific a selector is allowed to be.The methodologies covered in this section
Methodology | Core philosophy |
|---|---|
BEM | Encode structure in the class name itself: Block, Element, Modifier |
SMACSS | Categorize every rule as Base, Layout, Module, State, or Theme |
OOCSS | Separate structure from skin so the same structural class can wear different visual "skins" |
Utility-First | Compose designs from many small, single-purpose classes applied directly in markup |
CUBE CSS | Pragmatically blend utilities, BEM-like blocks, and explicit exceptions |
ITCSS | Order your stylesheet imports from low-specificity/broad-reach to high-specificity/narrow-reach |
Why this still matters, even with components
None of these ideas were created for React or Vue — most predate component frameworks by years, back when a single global
style.css served an entire site. Modern tooling has since taken over one of their biggest jobs: scoping. CSS Modules, CSS-in-JS libraries, and utility frameworks like Tailwind all give you automatic or convention-based scoping without hand-rolled naming discipline.CSS
/* The problem these methodologies were built to prevent: */
.card { padding: 1rem; }
.sidebar .card { padding: 1.5rem; } /* now more specific */
.homepage .sidebar .card { padding: 2rem; } /* more specific still */
.card.card--dashboard.is-active { padding: 2.5rem !important; } /* the escape hatch */
/* Nobody can safely delete any of these rules without checking every page */The underlying principles outlive the specific tooling
Even in a codebase using CSS Modules or styled-components, you still have to decide how to categorize styles (is this a base style, a component style, a one-off override?), how granular to make a component's internal class names, and when a "utility" class is the right tool versus a full component style. BEM's explicitness, SMACSS's categorization, and ITCSS's specificity ordering are all still useful mental models — they've just moved from being enforced by naming convention to being enforced (or not) by your build tooling.
The following pages walk through each methodology in turn, what problem it specifically targets, and a worked example so you can see the philosophy applied to real markup and CSS.
Next
Start with the most widely recognized naming convention: BEM Methodology.