So ähnlich ging es wohl den Kollegen der russischen Suchmaschine Yandex. Wie sah zu der Zeit ein typischer Webentwicklungsprozess aus? Der Designer tüftelt mehrere Mockups aus. Zur Wohltat aller Beteiligten kann dieser sein Design auch gleich umsetzen in HTML und CSS. Die Dateien werden an den Entwickler überreicht, der dem Ganzen mit einer serverseitigen Programmiersprache Leben einhaucht. Tausende Zeilen Code in Granit gemeißelt, um bis zur Erscheinung von HTML18 nicht mehr angerührt zu werden — genau dort liegt das Problem.
Die alte Leier: Webseiten sind nicht mehr statische Layouts sondern eine flexible Anordnung von Komponenten. Warum wird nicht so programmiert? Wer kann schon von sich behaupten, dass er sich sofort in einem sechs Monate alten Projekt zurechtfindet? Was macht eigentlich die Klasse .arrow-oben-btnInhalt? Warum ist hier alles voller IDs und warum liegt hier eigentlich Stroh?
BEM ist lediglich eine gemeinsame Einigung auf eine bestimmte Namenskonvention. Es ist kein Framework, hier gibt es nichts zu installieren. Die Vorteile sprechen für sich:
Der Block ist eine unabhängige Einheit mit eigener Bedeutung im Gesamtlayout und repräsentiert ein abgegrenztes Teil des Interfaces. Das Element ist immer Teil eines Blockes und ist funktionell als auch semantisch an diesen gebunden. Es hat keine Bedeutung außerhalb seines zugehörigen Blockes. Blöcke wiederum benötigen nicht zwingend Elemente. Trennung mit zwei Unterstrichen. Modifier sind Kennzeichnungen, die Blöcken oder Elementen zugewiesen werden können. Sie definieren Eigenschaften oder Zustände. Trennung mit zwei Bindestrichen.
Schreibt man statt haus__fenster lediglich fenster so kommt die Frage auf: Was für ein Fenster? Ein Bootsfenster? Ein metaphorisches Fenster in eine Fantasiewelt? BEM schafft hier Ordnung, auch wenn es anfangs etwas mehr Schreibarbeit erfordert.
Für Klassen, die lediglich eine bestimmte Aufgabe erledigen, muss die BEM Methodik natürlich nicht angewandt werden. Eine sogenannte “utility class” wäre beispielsweise…
.uppercase {
text-transform: uppercase;
}
Im Netz kursieren viele Konzepte für Namenskonventionen. Manche halten BEM für unnötig ausführlich und ich stimme zu, dass es nicht der heilige Gral ist. Ich selber kombiniere Elemente aus BEM mit Ansätzen aus SMACSS. Ein Designer erstellt seine Arbeit systematisch und begründbar mit Rastern und Hierarchien, er bedenkt Faktoren wie Skalierbarkeit und Langlebigkeit. Das unterscheidet den Profi vom Laien. Diese Gründlichkeit muss auch hinter den Kulissen im Code angewandt werden.
Wichtig ist nur, dass du dir beim Programmieren bewusst bist, warum du die jeweilige Klasse nun so benannt hast und wie sich das Objekt im großen Ganzen einfügt. Für Teams ist es hilfreich, eine “Codingrichtlinie” schriftlich festzuhalten. Das bedeutet anfangs etwas Arbeit, aber zahlt sich definitiv aus, wenn euch am Ende nicht die gesamte Codebasis um die Ohren fliegt und ihr !important Flags wie Bonbons an Karneval verteilen dürft.