Teil 3:
Wie BEM unsere Art CSS zu schreiben veränderte

Im dritten Teil unserer Artikelserie CSS-Kurs für Contao wollen wir euch BEM vorstellen, eine Namenskonvention für CSS-Klassen. BEM hat unsere Art CSS zu schreiben von Grund auf verändert. Vielleicht verändert es auch Eure.

In den letzten beiden Artikeln haben wir an der ein oder anderen Stelle schon durchblicken lassen, dass wir seit ein paar Projekten auf BEM setzen. Inhaltlich betrachtet, hätten wir BEM durchaus auch schon im ersten Artikel CSS-Klassen benennen, aber auch im zweiten Teil CSS einfach halten unterbringen können.

Nachdem wir aber zuletzt einen Hinweis bekamen, dass wir mit jeweils über 2.000 Wörtern hart an der Grenze der zumutbaren Artikellänge liegen, sind wir eigentlich ganz froh, dass wir uns dazu entschieden haben, BEM einen eigenen Artikel zu widmen.

BEM steht für BLOCK, ELEMENT, MODIFIER und ist eine von der russischen Suchmaschine Yandex entwickelte Namenskonvention (zur Website). Wir nutzen BEM in erster Linie, um unsere CSS Klassen transparent und für andere Entwickler nachvollziehbar zu halten. Die Regeln für die Klassen-Benennung sind zwar etwas strikter, aber wenn man sie erstmal verinnerlicht hat, gehen auch sie relativ leicht von der Hand.

Die BEM-Syntax

BEM stellt es euch grundsätzlich frei, welche Art von Trenner ihr zwischen block und element oder modifier verwenden wollt. Wenn ihr aber andere Artikel zum Thema BEM lest, werdet ihr, gerade bei neueren Artikeln, häufig unsere Schreibweise mit doppeltem Unterstrich bzw. doppeltem Bindestrich wiederfinden:

.block {}
.block__element {}
.block--modifier {}

Als .block bezeichnen wir die übergeordnete Komponente, .block__element ist ein Kindelement von .block und .block--modifier ist eine Variante oder Version von .block.

Ein Beispiel: BEM-Klassen im Einsatz

Um die Zusammenhänge zwischen Block, Element und Modifier ein wenig zu verdeutlichen, ein Beispiel: Wir wollen die Navigation einer Website gestalten.

<nav class="mod_navigation block">
    <ul class="level_1" role="menubar">
        <li class="first"><a>Home</a></li>
        <li><a>Über uns</a></li>
        <li class="last"><a>Kontakt</a></li>
    </ul>
</nav>

Nun wollen wir die BEM-Klassen-Bezeichnungen den einzelnen Teilen unserer Navigation zuordnen:

• Block: Unsere Navigation ist eine unabhängige Komponente, wir geben ihr deshalb die Klasse .nav.
• Element: unsere ungeordnete Liste liegt innerhalb von .nav und bekommt, um die Zugehörigkeit zur Komponente zu verdeutlichen, die Klasse .nav__list.
• Modifier: da es sich bei unserer Navigation um eine Hauptnavigation mit kleinen grafischen Abweichungen handelt, geben wir ihr zusätzlich die Klasse .nav--main.

<nav class="mod_navigation nav nav--main block">
    <ul class="level_1 nav__list" role="menubar">
        <li class="first"><a>Home</a></li>
        <li><a>Über uns</a></li>
        <li class="last"><a>Kontakt</a></li>
    </ul>
</nav>

Der Vorteil: Durch den gemeinsamen Stamm .nav lassen sich so relativ leicht alle zusammengehörigen Klassen erkennen und das sowohl in unserer CSS als auch in unserem HTML-Code.

Der Nachteil: Durch die Wiederholung des Stamms werden die Klassenbezeichnungen länger. Damit dies nicht in ellenlangen Klassennamen ausartet, lautet eine wichtige Regel, dass die Klassenbezeichnung nicht die HTML-Baumstruktur widerspiegeln soll.

Statt also das Listenelement als Kind der Liste zu deklarieren, benennen wir es lediglich als (weiteres) Kind der Navigation. Das Gleiche gilt für unseren Anker.

falsch:

.nav {}
.nav__list {}
.nav__list__item {}
.nav__list__item__link {}

richtig:

.nav {}
.nav__list {}
.nav__item {}
.nav__link {}

So bleiben die Klassennamen einigermaßen kurz, trotzdem ist der Zusammenhang zwischen Blöcken und Elementen sofort erkennbar.

Tatsächlich hat es auch bei uns eine Weile gedauert, bis wir uns mit der ungewohnten Schreibweise von CSS-Selektoren anfreunden konnten. Ja, BEM ist hässlich. Aber ist das ein Grund, es nicht zu nutzen?

Und wenn wir mal ehrlich sind, spielt doch die Ästhetik von CSS-Klassennamen eher einer untergeordnete Rolle, oder? Der Vorteil, der sich allerdings daraus ergibt, Blöcke, Elemente und ihre Modifikationen auf einen Blick unterscheiden zu können, ist nicht zu unterschätzen.

Hinzu kommt, dass sich die BEM-Syntax in einer Contao-Website auf den ersten Blick erkennen lässt. Durch die doppelten Unterstriche und Bindestriche werdet ihr eure eigenen Klassen und die Contao-Klassen immer auseinander halten können.

Wenn es darum geht, BEM in Contao zu verwenden, bin ich immer wieder hin- und hergerissen. Am Liebsten würde ich große Teile meines Codes nach der BEM-Syntax strukturieren. Gleichzeitig möchte ich aber in Contao möglichst wenige Templates anpassen, um mir nicht bei späteren Updates und größeren Änderungen am Contao-Core Steine in den Weg zu legen (siehe auch Teil 1: Die Praxis).

Deswegen fahren wir momentan noch ein wenig zweigleisig und setzen BEM noch nicht so konsequent ein, wie wir es manchmal gerne würden. Aber Hoffnung ist in Sicht: Seit längerer Zeit ist die Rede von einen Contao-Call zum Thema CSS-Standards. Noch steht allerdings kein Termin fest.

Contao hat durch die einfache Einbindung von externen Stylesheets und sogar der Verarbeitung von SCSS und LESS-Dateien bereits eine Menge getan, um Entwicklern den Umgang mit CSS einfacher zu machen. Jetzt wäre es an der Zeit, auch die noch aus Typolight-Zeiten stammenden Klassenbezeichnungen zu überdenken. Wir werden auf jeden Fall versuchen, bei diesem Call dabei zu sein.