Wenn Projekte wachsen, leidet vanilla CSS unter globalem Geltungsbereich — jeder Selector konkurriert global, Specificity-Kriege entstehen, und niemand wagt es, eine Regel zu löschen. Methodologien erzwingen Struktur und Namenskonventionen, um CSS wartbar zu halten.
Eine Namenskonvention, die Beziehungen explizit macht und Specificity flach hält (alle einzelnen Klassen):
{ }
{ }
{ }
{ }
<div class="card card--featured">
<h2 class="card__title">...</h2>
</div>
BEMs Wert: Klassennamen dokumentieren sich selbst, sind nach Konvention scoped und einheitlich niedrig-spezifisch (keine Nesting-/ID-Kriege).
Stile aus winzigen, einzweckigen Klassen direkt im Markup zusammenstellen:
<div class="flex items-center gap-4 p-6 rounded-lg shadow">...</div>
Vorteile: keine Benennung, kein ungenutztes CSS (bereinigt), konsistente Design-Token. Nachteile: ausschweifendes HTML. Extrem beliebt für seine Geschwindigkeit und Konsistenz.
Der moderne Ansatz in Component-Frameworks — Styles auf eine Komponente scoped, damit sie nicht austreten können:
import styles from "./Card.module.css"; // class names are hashed/localized
<div className={styles.card}>...</div> // → .Card_card__a1b2 (unique)
Dies löst das Problem des globalen Geltungsbereichs mechanisch statt durch Konvention.
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
Alle bekämpfen die gleichen Feinde: Specificity Creep, Namenskollisionen, tote Code und unvorhersehbare Kaskaden. Ob durch Benennung (BEM), Utilities (Tailwind) oder Scoping (Modules), halten sie CSS vorhersehbar und sicher zu ändern in großem Maßstab.
Große CSS-Codebases kollabieren unter globalem Geltungsbereich und Specificity-Kriegen ohne Disziplin.
Das Auswählen und konsistente Anwenden einer Methodologie (heute üblicherweise BEM, Tailwind oder scoped CSS Modules) ist das, was Styles modular, löschbar und konfliktfrei hält, wenn Team und Codebase wachsen.