Das Schwierige an CSS ist, dass es so einfach ist. Obschon leicht erlernt, ist es jedoch schwer zu strukturieren und wirkt oft undurchschaubar. Findet man keinen sauberen Weg, seinen Code zu organisieren, wächst die Codemenge oft exponentiell zur Projektlänge an.
In Just Try and Do a Good Job schreibt Chris Coyier, dass er weder Namenskonventionen noch andere spezielle Methodiken nutzt, um sein CSS zu schreiben. Vielmehr versucht er mithilfe seiner Erfahrung und weniger Richtlinien, immer gute Arbeit (a good job) zu machen. Er schränkt dabei ein, dass er hauptsächlich alleine arbeitet und so seinen Stil leicht einhalten kann. Für Teams reicht die Arbeitsanweisung »Do a good job« selten aus. Zumal oft unterschiedliche Vorstellungen davon herrschen, was genau das denn bedeutet, trotz Coding Richtlinien.
Das Entwicklungsteam von ZEIT ONLINE hat hier viele, oft schmerzliche Erfahrungen gesammelt. Zu Zeiten des Relaunch 2009 hatten wir für uns einen CSS-Schreibstil entwickelt, der unseren damaligen Arbeitsumständen sehr entgegen kam und am damaligen state of the art orientiert war. Leider wissen wir heute, dass wir damit CSS gebaut haben, das zwar gut funktioniert, aber sehr schwierig zu warten ist. Die Weiterentwicklung der Seite führt zu immer mehr Code. Da nie ganz klar ist, welcher Code wo noch in Gebrauch ist, ist es gefährlich, eigentlich überflüssigen Code zu entfernen. Der sogenannte code bloat kann die Website-Performance aber schnell verschlechtern. Wir haben natürlich immer wieder an dem Problem gearbeitet, aber die gewünschten Performance-Werte letztlich nie erreichen können – oder auch nur unsere Entwickler besonders entlasten.
Aus diesem Grund haben wir uns für die Einführung der sehr rigiden Namenskonvention BEM entschieden. BEM steht für Block, Element, Modifier, was schon die drei Entitäten beschreibt, in die wir unseren CSS-Code in Zukunft unterteilen. Blöcke sind unabhängige Einheiten in einer Website, die für sich allein stehen können und einen Teil der Nutzeroberfläche repräsentieren. Dies kann beispielsweise ein Logo, ein Suchformular oder ein Menü sein. Blöcke können weitere Blöcke enthalten, was sie von den Elementen unterscheidet. Diese sind für sich allein gestellt nutzlos, funktionieren nur in ihrem Block. Zu guter Letzt gibt es noch Modifikatoren. Das sind zusätzliche Klassen, die an Blöcke oder Elemente geschrieben werden, um unterschiedliche Status abzubilden. Alle Blöcke, Elemente und die Modifikatoren werden durch Klassen repräsentiert, die per Benennung grob ihre Aufgabe und genau ihre Beziehung zueinander ausdrücken. Im Stylesheet wird ausschließlich mit diesen Klassen gearbeitet, alle anderen Selektoren sind quasi verboten.
The one „rule“ish thing I really believe in: keep your selector specificities fairly low and flat across your whole project. — Chris Coyier
Die Namenskonvention mit den doppelten Unterstrichen oder Minuszeichen – die man durchaus nach seinen Vorstellungen ändern kann – und das zweifelsohne hohe Aufkommen an Klassen-Attributen im HTML wirken zunächst etwas ungewöhnlich. Die einzelnen Blöcke werden dadurch voneinander völlig unabhängig. Sie können leicht und sicher editiert werden. Die Spezifität aller Elemente ist auf zwei Stufen festgezurrt, die Kaskade damit außer Kraft gesetzt. Aber gerade das hilft; vor allem in den ganz großen Projekten, in denen nicht mehr jeder jeden Codeblock kennt. Was also zunächst nach zusätzlicher Arbeit aussieht, kommt der Realität der Entwicklung und vor allem der Weiterentwicklung einer Nachrichtenseite sehr entgegen. Ziel ist es letztendlich, Code zu schreiben, der gut und sicher zu modifizieren ist. Diese Anforderung ist durch die vollständige Modularisierung und die flache Hierarchie der Klassen in BEM erfüllt.
Den Aufwand, den der Einsatz einer solchen Namenskonvention mit sich bringt, fangen wir durch Tools wie Sass (siehe auch BEM-Notation) oder grunt zumindest zum Teil wieder ab. In der Automatisierung liegt dann auch die Möglichkeit, den Code laufend zu prüfen und zu messen. Und nur wer misst, kann seine Performance erhöhen.
Nico Brünjes ist Teamleiter Frontend bei ZEIT ONLINE.