What are the five categories SMACSS sorts CSS rules into, and what do namespace prefixes such as `l-`, `is-`, `c-` and `u-` tell a reader about a class?

## SMACSS is a taxonomy, not a grammar BEM tells you how to *spell* a name. SMACSS — Scalable and Modular Architecture for CSS, by Jonathan Snook — tells you what *kind* of rule you are writing. Its claim is that most stylesheet confusion comes from mixing rules with different lifecycles and different blast radii in the same place, and that sorting them into a small fixed set of categories resolves most of it. **Base** rules style bare elements with no class at all: `body`, `a`, `h1`, `input`. They set defaults for the whole document and are the only place element selectors belong. **Layout** rules position the major regions — header, sidebar, main column, grid container. They are prefixed `l-` (`l-header`, `l-grid`) so a reader can see at once that the rule concerns page structure rather than a component's internals. Layout rules are the ones legitimately allowed to own outer geometry. **Module** rules are the reusable components: a card, a menu, a search form. This is the bulk of any stylesheet, and it is the category BEM's block grammar is describing. Modules get sub-components and variants; SMACSS suggests naming those after the module itself, which is essentially the same idea as BEM's element prefix. **State** rules describe a transient condition, usually toggled at runtime: `is-active`, `is-hidden`, `is-collapsed`, `has-error`. Two properties distinguish them. They are meant to be applied and removed dynamically, and they are allowed to override module rules — which is why they read as an adjective rather than a component name. **Theme** rules carry swappable visual treatment — the parts you would change to reskin a product without touching structure. ```css /* base */ a { color: #06c; } /* layout */ .l-sidebar { inline-size: 18rem; } /* module */ .search-form { display: flex; } /* state */ .is-hidden { display: none; } ``` ## Namespaces generalise the prefix idea The useful kernel of SMACSS — a one- or two-character prefix that announces a class's role — was generalised into a broader namespacing convention popularised by Harry Roberts. The common set is: - `o-` **object**: an abstract, structural pattern with no cosmetics, reused widely (a media object, a wrapper). Dangerous to change: it is used in places you have not seen. - `c-` **component**: a concrete, designed piece of UI. Safe to change: its effects stop at the component. - `u-` **utility**: a single-purpose helper that does one thing everywhere. Also dangerous to change, and by design hard to override. - `t-` **theme**: a theme-scoped visual treatment. - `s-` **scope**: a bounded area with different rules, typically CMS-authored content. - `is-` / `has-`: a temporary state, expected to be toggled by script. - `js-`: a hook for behaviour only, carrying **no** declarations at all. ## Why the prefix earns its character count The question a reader asks before editing a rule is "what will I break?" A bare class name cannot answer it; you have to grep. A prefix answers it in the class attribute itself: ```html <div class="o-media c-comment c-comment--pinned is-unread js-comment"> ``` That one line says: an abstract layout pattern, a concrete component with a variant, a runtime state, and a behavioural hook. An engineer can now change `.c-comment` freely, will think twice before changing `.o-media`, and knows that deleting `js-comment` breaks JavaScript rather than styling. The `js-` convention is the one with the sharpest payoff. When behavioural code queries the same class that styles a component, a purely visual rename silently breaks a feature, and neither the linter nor the type checker notices. Keeping a separate, declaration-free hook class makes that coupling explicit and independently renameable. ## How these coexist with BEM They compose rather than compete: SMACSS says which bucket a rule belongs to, the namespace prefix advertises that bucket in the markup, and BEM's grammar spells the component name inside it — producing classes such as `.c-card__title--compact`. The cost is more characters and a second convention to teach; the benefit is that a reader knows a rule's category and its blast radius without opening a file. ## The failure mode to watch for Prefixes are load-bearing only while they are honest. A `u-` utility that quietly grows component-specific declarations, or a `js-` hook that acquires a background colour, is worse than an unprefixed class because readers still trust the label. Whatever set you adopt, it needs to be written down and checked — by lint where the pattern is expressible, by review where it is not.