Katalog
method#Software‑Engineering#Architektur#Delivery

Block Element Modifier (BEM)

BEM ist eine CSS-Namenskonvention und Methodik zur strukturierten Benennung von Klassen, die Wiederverwendbarkeit und Vorhersagbarkeit fördert.

Block Element Modifier (BEM) ist eine CSS-Namenskonvention und Methodik zur strukturierten Organisation von Komponenten.
Etabliert
Mittel

Klassifikation

  • Mittel
  • Technisch
  • Architektur
  • Fortgeschritten

Technischer Kontext

Styleguidist oder Storybook zur DokumentationCSS-Linter (z. B. stylelint) mit BEM-RegelnBuild-Tools (Webpack, Vite) für scoped CSS-Module

Prinzipien & Ziele

Klare Trennung von Block, Element und Modifier.Vorhersagbare, wiederverwendbare Klassennamen statt kontextabhängiger Selektoren.Konvention über Konfiguration: einfache Regeln statt projektinterner Sonderfälle.
Umsetzung
Team, Domäne

Use Cases & Szenarien

Kompromisse

  • Übermäßige Fragmentierung von Klassen bei zu feiner Block-Aufteilung.
  • Teamweite Konventionsstreitigkeiten ohne klare Governance.
  • Unkontrollierte Erweiterung von Modifiers führt zu Namensexplosion.
  • Beschränke Modifier auf tatsächlich variable Zustände.
  • Vermeide tief verschachtelte Block-Hierarchien; favorisiere flache Strukturen.
  • Nutze Tooling zur Validierung der Namenskonvention (Linter, Tests).

I/O & Ressourcen

  • Design-System oder Styleguide
  • Liste bestehender Klassen und Komponenten
  • Build/Testing-Tooling (Linter, Visual Regression)
  • Standardisierte Klassennamenskonvention
  • Dokumentierte Komponenten-Blocks
  • Reduzierte Styling-Konflikte

Beschreibung

Block Element Modifier (BEM) ist eine CSS-Namenskonvention und Methodik zur strukturierten Organisation von Komponenten. Sie fördert klare, wiederverwendbare Klassen und trennt Struktur von Zuständen. BEM unterstützt skalierbare Stylesheets, erleichtert Zusammenarbeit in Teams und reduziert Seiteneffekte beim Styling. Es eignet sich besonders für modulare Frontend-Architekturen und langfristige Wartbarkeit.

✔

  • Verbesserte Lesbarkeit und Vorhersagbarkeit von Styles.
  • Erleichterte Wiederverwendung von Komponenten über Projekte hinweg.
  • Geringere Seiteneffekte durch explizite Klassengrenzen.

✖

  • Benötigt Disziplin bei Namensgebung; inkonsistente Anwendung führt zu Unordnung.
  • Kann Boilerplate in klassennamen erzeugen, insbesondere bei tief verschachtelten Strukturen.
  • Nicht unmittelbar kompatibel mit allen CSS-in-JS-Ansätzen ohne Mapping.

  • Anzahl eindeutiger Blöcke

    Misst wie viele unabhängige BEM-Blöcke in der Codebasis existieren.

  • Konflikte durch globale Selektoren

    Anzahl von Stilkonflikten, die auf globale Selektoren zurückzuführen sind.

  • Durchschnittliche Klassennamenlänge

    Metrik zur Abschätzung von Boilerplate und Lesbarkeit durch Klassennamenlänge.

Einfache Karten-Komponente

Ein Card-Block (.card) mit Elementen wie .card__title und Modifiers wie .card--featured.

Navigationsleiste

Block .nav mit Elementen .nav__item und Modifiern für aktive Zustände .nav__item--active.

Formular-Layout

Form-Block (.form) mit .form__field und Zustandsmodifizierern wie .form__field--error.

1

Start: Definiere minimale BEM-Regeln und kommuniziere sie im Team.

2

Pilot: Migriere eine kritische Komponente und evaluiere Auswirkungen.

3

Rollout: Erweitere Migration, richte Linter ein und ergänze Dokumentation.

⚠️ Technische Schulden & Engpässe

  • Alte globale Selektoren, die eine Migration blockieren.
  • Unvollständige Dokumentation der verwendeten BEM-Konvention.
  • Fehlende Linter-Regeln zur Durchsetzung der Namenskonvention.
global-cssnaming-complexitytooling
  • Verwendung von Modifiers zur Darstellung reiner Layout-Abweichungen anstatt semantischer Zustände.
  • Erstellung von Block-Namen, die sich stark am DOM-Aufbau orientieren und nicht an Komponenten.
  • Mischen von BEM-Konventionen mit projektweiten globalen Selektoren ohne Abgrenzung.
  • Zu feine Blocks führen zu hoher Klassenanzahl und Wartungsaufwand.
  • Unklare Grenzziehung zwischen Block- und Element-Verantwortung.
  • Blindes Kopieren von Namensmustern aus anderen Projekten ohne Kontextanpassung.
Fundiertes CSS-WissenVerständnis von Frontend-Baugruppen und KomponentenarchitekturFähigkeit, Konventionen zu dokumentieren und durchzusetzen
Modularität und WiederverwendbarkeitVermeidung globaler StilkonflikteVorhersagbare Selektor-Hierarchie
  • • Bestehende Legacy-Styles erfordern schrittweise Migration.
  • • Projektspezifische Ausnahmen können Konventionen abschwächen.
  • • CSS-in-JS-Patterns benötigen zusätzliche Mapping-Strategien.