Why CSS naming conventions matter
In small projects, any class name works. But when your CSS exceeds 1000 lines or you work in a team, lack of conventions becomes real technical debt. 40% of CSS maintenance time is spent understanding what each class does and whether it's safe to modify.
Typical problems without methodology: ambiguous names like .title repeated across 15 different components, uncontrollable specificity forcing !important, and fear of deleting CSS because you don't know what might break.
A solid convention like BEM or SMACSS solves three fundamental problems: predictability (you know what a class does just by reading it), reusability (context-independent components), and scalability (adding features without breaking existing code).
Companies like Airbnb, GitHub, and Spotify publicly document their CSS style guides. It's no coincidence: teams of 50+ developers need to instantly understand each other's code. Investment in naming pays off multiplied in onboarding speed and bug reduction.
BEM: the most adopted methodology
BEM (Block Element Modifier) divides UI into independent blocks containing elements and can have modifiers. Syntax: .block__element--modifier. Real example: .card__title--large.
Block: Autonomous reusable component (.card, .button, .modal). Must make sense on its own without parent context.
Element: Part of block that has no independent meaning (.card__title, .card__image, .card__footer). Always preceded by block with double underscore.
Modifier: Variant of block or element (.button--primary, .card__title--centered). Should never be used alone, always accompanies base class.
Real advantages of BEM: you eliminate specificity conflicts (everything has the same), you instantly know HTML hierarchy by just looking at classes, and components are portable between projects. Code is more verbose, but clarity widely compensates.
Common mistakes: nesting elements (.block__element__subelement is incorrect, should be .block__subelement), using modifiers without base class, and creating blocks too large that should be multiple independent blocks.
SMACSS and component states
SMACSS (Scalable and Modular Architecture for CSS) organizes styles into five categories: Base, Layout, Module, State and Theme. The most useful part are state classes with is- or has- prefix.
Examples: .is-active, .is-disabled, .is-loading, .has-error, .has-dropdown. These classes are implementation-independent and can combine with any component.
The advantage is semantic portability: .is-active works equally in tabs, menus, buttons or accordions. Your JavaScript only needs to add/remove these classes without worrying about specific CSS implementation.
Combine SMACSS with BEM for maximum clarity: <button class="btn btn--primary is-loading">. BEM defines structure, SMACSS handles temporary state.
Classes has-* indicate component contains something: .has-dropdown (has dropdown menu), .has-icon (contains icon), .has-sidebar (includes sidebar). This allows applying conditional styles without inspecting child HTML.
For temporary states controlled by JS (loading, error, success), always use classes instead of inline styles. This maintains separation of concerns and allows animating transitions with CSS.
Atomic CSS and utility-first with Tailwind
Atomic CSS breaks the traditional model: instead of creating semantic classes, you compose styles with single-purpose utility classes. Tailwind popularized this approach: class="flex items-center justify-between p-4 bg-blue-500 text-white rounded-lg".
Real advantages: you don't have to invent class names, there's no unused CSS (smaller tree), and changes are local (you modify component without affecting others). Final build with PurgeCSS eliminates everything unused.
Disadvantages: verbose HTML, hard to read without practice, and global design changes require find-and-replace across multiple files (though with React/Vue components this is mitigated).
For new projects, utility-first is excellent: you iterate fast without naming fatigue. For legacy projects or large teams with established design, BEM offers better long-term maintainability.
You can combine both: utilities for spacing/layout (mt-4, flex) and BEM for complex components with state logic. This hybrid approach leverages the best of both worlds.
Rule of thumb: if you need more than 8 utility classes for an element, you should probably extract a component or create a semantic class.