As projects grow, plain CSS suffers from global scope — every selector competes globally, specificity wars erupt, and nobody dares delete a rule. Methodologies impose structure and naming conventions to keep CSS maintainable.
A naming convention that makes relationships explicit and keeps specificity flat (all single classes):
{ }
{ }
{ }
{ }
<div class="card card--featured">
<h2 class="card__title">...</h2>
</div>
BEM's value: class names are self-documenting, scoped by convention, and uniformly low-specificity (no nesting/id wars).
Compose styles from tiny single-purpose classes directly in markup:
<div class="flex items-center gap-4 p-6 rounded-lg shadow">...</div>
Pros: no naming, no unused CSS (purged), consistent design tokens. Cons: verbose HTML. Hugely popular for its speed and consistency.
The modern approach in component frameworks — scope styles to a component so they can't leak:
import styles from "./Card.module.css"; // class names are hashed/localized
<div className={styles.card}>...</div> // → .Card_card__a1b2 (unique)
This solves the global-scope problem mechanically rather than by convention.
OOCSS — separate structure from skin, reuse objects
SMACSS — categorize rules (base, layout, module, state, theme)
ITCSS — layer CSS by specificity (generic → explicit), low to high
All of them fight the same enemies: specificity creep, naming collisions, dead code, and unpredictable cascades. Whether via naming (BEM), utilities (Tailwind), or scoping (Modules), they keep CSS predictable and safe to change at scale.
Large CSS codebases collapse under global scope and specificity wars without discipline.
Picking and consistently applying a methodology (commonly BEM, Tailwind, or scoped CSS Modules today) is what keeps styles modular, deletable, and conflict-free as a team and codebase grow.