10. Entkoppelung von HTML und CSS

Die Idee, HTML und CSS voneinander zu entkoppeln, hört sich auf den ersten Blick charmant an, darf aber nicht falsch verstanden werden.

Gestaltung und Semantik können vollständig voneinander entkoppelt werden, indem wir nur noch mit Klassen arbeiten, Elementselektoren nicht mehr nutzen. Dadurch ist es vollkommen egal, ob wir mit der Klasse .code einen Link, einen Button, einen DIV-Container oder eine h3 stylen, alle werden dank der Klasse gleichartig gestaltet.

Allerdings schreiben wir unser CSS immer für einen konkreten Gestaltungsfall. Deshalb ist es unwahrscheinlich (obgleich durchaus möglich), dass wir die Klasse .teaser__headline zur Gestaltung eines Buttons anwenden. Der Nutzen der Klasse .teaser__headline liegt allerdings darin, dass wir bei ihrer Gestaltung nicht wissen müssen, ob sie am Ende eine h2, h3 oder h4 ziert. Mir persönlich ist allerdings wichtig, dass diese Klasse einem Überschriftenelement gegeben würde und keinem DIV oder SPAN.

Ich sehe in dem Vorteil auch eine Gefahr. Denn der Entwickler muss sich nur noch um die Verteilung von Klassen bemühen, wird aber auf der anderen Seite nicht zu einem vernünftigen HTML-Code angehalten. Was wird mit einer solchen Vorgehensweise gewonnen? Es bleiben nur noch Anpassungen an die Optik des jeweiligen Projekt übrig. Anpassungen an eine abweichende Struktur des Standard-Moduls sind nicht mehr notwendig.

Ich denke nicht, dass die damit einhergehende Zeitersparnis rechtfertigt, der Struktur einer Webseite weniger Beachtung zu geben. Webseiten sind nicht nur schöne Optik, sie bestehen auch aus einer sinnvollen Struktur. Beides sollte ein Frontendentwickler beherrschen und pflegen.

Eine Entkoppelung wird es nie geben

Eine Entkoppelung von HTML und CSS wird es nie geben, schliesslich ist CSS die Sprache, mit der eine HTML-Struktur gestaltet werden soll. Beide sind also miteinander verwoben. Der objektorientierte Ansatz scheint diese Verbindung so weit wie möglich verdrängen zu wollen. Die Abstraktion um der Abstraktion willen ist aber nicht zielführend. Sparsames, semantisches HTML sollte mit ebenso sparsamem und logisch durchdachtem CSS gestaltet werden.

Was alle objektorientierten Ansätze hingegen schaffen, ist eine Entkoppelung von Gestaltung (CSS) und semantischem HTML. Nimmt man vor allem BEM und OOCSS ernst, dann ist es egal, ob die Klasse .btn an einem Button ist (oder zumindest einem Link). Und genau dies sehen wir immer wieder bei JavaScript-zentrierten Webseiten. Da werden SPAN oder DIV mit der Klasse .btn versehen und mit ein wenig JavaScript zu Buttons verwandelt.

Eine Klassen-Abstraktion gerät irgendwann an ihre Grenzen. Der CSS-Zengarden hat uns zwar gezeigt, dass man eine identische HTML-Struktur sehr unterschiedlich gestalten kann. Aber der CSS-Zengarden war nie praxisnah. Er arbeitete mit einer einfachen Struktur, die zudem bewusst mit leeren Elementen und zusätzlichen Klassen ergänzt wurde, damit die jeweiligen Designer/Entwickler sich austoben konnten.

Wenn wir in der Praxis die Webseite einer Bank, eines Shops oder die eigene Webpräsenz neu gestalten, dann geht es doch normalerweise nicht nur um einen neuen Anstrich. Ich hatte in meiner beruflichen Laufbahn nur zwei Fälle, bei dem der Kunde bewusst nur die Optik verändern wollte. Im ersten Fall sollten die Templates nicht verändert werden. Im zweiten Fall konnten sie nicht verändert werden, weil die deutsche Niederlassung einer amerikanischen Firma keine Zugriffsrechte bekam. Aber das sind Ausnahmefälle.

Üblicherweise wird das komplette HTML neu erstellt. Denn es gibt nicht nur ein komplett neues Design, auch die Ansprache verändert sich oft, die Seitenstruktur ebenso. Das ist weder schlimm noch ungewöhnlich. Und da HTML und CSS miteinander verknüpft sind, bedeutet ein Relaunch immer eine Arbeit auf beiden Ebenen.

Wenn dann noch ein neues CMS eingeführt wird, kann es sein, dass die Arbeit noch umfangreicher wird. Schliesslich gibt es genügend Contentmanagementsysteme, die nicht nur den Inhalt verwalten (content managen), sondern auch eine eigene Struktur von sich aus ausgeben. So kann es sein, dass man mit CMS-eigenen Klassen, IDs und Strukturen arbeiten muss. Auch in diesem Falle ist also wieder eine Anpassung unserer Ansätze bei HTML und CSS notwendig.

Elemente dürfen direkt gestylt werden

Alle objektorientierten Ansätze propagieren die Verwendung von Klassen an Stelle normaler Elementselektoren. CSS bietet eine grosse Auswahl an Selektoren, doch diese werden bewusst negiert. Es wird eine größere Flexibilität in Aussicht gestellt, indem man sich vom existierenden HTML unabhängig macht.

Dabei kommen die meisten Elemente mit drei eingebauten Selektoren: dem Element selber, sowie mit den Pseudoelementen :before und :after. In Einzelfällen können auch Selektoren wie :first-child oder :nth-of-type(odd) weiterhelfen. Natürlich kann man sich mit zusätzlichen Klassen oder Elementen behelfen. Aber wenn uns doch diese Werkzeuge zur Verfügung stehen, warum sollten wir sie nicht nutzen?

Best Practices statt absoluter Abstraktion

Anstatt die Verwendung von CSS stark zu abstrahieren, sollten wir uns lieber um Best Practices kümmern, diese vereinheitlichen und möglichst breit kommunizieren. Dabei darf unsere Konzentration nicht auf CSS allein beruhen. Die andere Seite der Medaille ist weniger hübsch und spannend, gibt dem Ganzen aber einen Sinn: HTML. Nur mit einer gesunden HTML-Basis macht ein gutes CSS ein gutes Endprodukt.

Da Semantik etwas sehr individuelles ist, das sich nicht über alle möglichen Projekte hinweg abstrahieren lässt, kommt es weniger auf starre Regeln, als auf gute Beispiele an. Anhand dieser Beispiele kann man die eigene optimale Lösung finden, die auf das aktuelle Projekt passt.

Semantische Klassen

Die oft zitierten “semantischen Klassen” gibt es im Wortsinne nicht. Semantik wird durch HTML-Elemente repräsentiert. Klassen existieren als HTML-Attribute, damit man zusätzliche Ansatzpunkte für die Gestaltung einer Webseite schaffen kann. Sie sind also ganz bewusst Teile der Gestaltung, nicht der Semantik. Wir sprechen besser nicht von semantischen, sondern von pflegbaren Klassen.

Die Benennung einer Klasse nach visuellen Kriterien ist nicht falsch, sie ist allerdings unpraktisch. Ein Element mit der Klasse .rot steht in der Gefahr, dass es im Laufe des Projektes oder in einem Folgeprojekt blau oder schwarz formatiert wird. Eine Klasse .warnung ist da besser. Diese Klasse gibt keine optischen Informationen, sie informiert über die inhaltliche Aufgabe des betreffenden Elements. Sie ist dadurch auch lesbarer als .hinweis1. Aber sie ist natürlich festgelegt. Auch die beiden folgenden Beispiele sind unpraktisch und irreführend:

1 <h2 class="h3">Tolle Überschrift</h2>
2 <div class="h3">Ich möchte eine Überschrift sein!</di\
3 v>

Die Klasse h3 hat weder aus der Überschrift zweiten Grades noch aus dem DIV eine Überschrift dritten Grades gemacht. Der einzige Zweck dieser Klasse ist es, eine bestimmte Optik zu transportieren. Und die Erschaffer dieser Klasse sahen wohl in der Analogie zur Überschriftenhierarchie eine gute Möglichkeit, sich die konkrete Optik zu merken.

Der Klassiker in dieser Hinsicht sind Buttons:

1 <a class="btn" href="link.html">ein Link, wie ein But\
2 ton gestaltet</a>
3 <h4 class="btn">eine Überschrift, wie ein Button gest\
4 altet</h4>
5 <div class="btn">ein semantisches Nichts, wie ein But\
6 ton gestaltet</div>

Die allgemeine Vorstellung, wie ein Button auszusehen hat, wird mit der Klasse .btn transportiert. Hierbei ist es egal, ob diese Klasse an einem Link, einer Überschrift oder einem DIV hängt. Dies alles hat allerdings nichts mit Semantik zu tun. Die Optik wird stimmen, die semantische Bedeutung wird nicht transportiert. Das ist auch nicht die Aufgabe von CSS. Besonders tragisch ist dies im Falle der Buttons.

Vor allem bei JavaScript-zentrierten Projekten/Applikationen sehen wir immer wieder nachlässiges HTML. Da bekommen dann SPAN-Elemente oder Links die Optik von Buttons verpasst und wenn man Glück hat, hat der Entwickler mit ziemlich viel JavaScript noch dafür gesorgt, dass diese falsch genutzten Elemente sich so verhalten, als wären sie ein Button. Warum nicht einfach einen Button nutzen?

In meinen Augen fördert das Gerede von semantischen Klassen den Eindruck, man könne HTML ersetzen oder zumindest ignorieren. Aber für ein gutes Frontend-Projekt sind alle drei Bestandteile notwendig: HTML, CSS und JavaScript und zwar in dieser Reihenfolge.

Doch machen wir uns nichts vor: eine vollkommen neutrale Auszeichnung zu Gestaltungszwecken ist zwar möglich, aber nicht notwendig und auch nicht anzustreben. Wir verbinden doch schliesslich mit den Inhalten einen Sinn. Warum sollten wir diesen dann nicht auch in den Klassen wiederspiegeln lassen?

Klassen werden von Menschen für Menschen geschrieben. Weder eine Suchmaschine, noch ein Browser oder ein Screenreader haben einen Nutzen von der Verwendung oder gar der Benennung von Klassen. Deshalb sollten Klassennamen von Entwicklern verstanden werden, damit sie diese problemlos nutzen können. Denken Sie dabei auch immer an Entwickler, die Ihr Projekt übernehmen werden. Wie schwer machen Sie es denen, Ihren Code zu verstehen?

Die einzige Ausnahme zu dieser Regel sind die Mikroformate. Hierbei werden fest definierte Klassennamen an (hoffentlich) semantische Elemente gesetzt, um diesen eine zusätzliche Bedeutungsebene zu geben und sie maschinenlesbar zu machen. So kann man Adressen und Termine maschinenlesbar auszeichnen.

Mikroformate sind allerdings nicht primär zur Gestaltung von Webseiten gedacht. Diese Abhandlung dreht sich um die Gestaltung von Webseiten und die adäquate Benennung von Klassen. Meiner Meinung nach gehorcht die Vergabe von Klassen für Design anderen Gesetzen, als bei den Mikroformaten.

Unterschiedliche Arten zu stylen

Alle bisherigen Überlegungen zur Abfassung eines Stylesheets sollten in Betracht ziehen, wie am Ende das resultierende CSS genutzt wird. Werden Templates erstellt und quasi mit der Verteilung von Klassen eine gewünschte Gestaltung erreicht? Oder werden in den Templates nur wenige Klassen eingesetzt, da die GEstaltung über die direkte Modifikation des CSS geschieht?

Das sind zwei grundsätzlich verschiedene Ansätze. Den ersten Ansatz kann man “HTML-fokussiert” nennen. Er ist besonders praktisch, wenn man schnell einen Prototypen erstellen möchte oder den Templateentwicklern einen Baukasten zur Verfügung stellen will. Frameworks wie Bootstrap und Foundation arbeiten genau nach dieser Methode.

Sollten Sie also HTML-fokussiert arbeiten, kann es sinnvoll sein, mit vielen Modifikatoren zu arbeiten.

Im Kontrast dazu steht die “CSS-fokussierte” Entwicklung. Hier werden zwar auch Klassen im Template verteilt, die eigentliche Gestaltungsarbeit geschieht aber unabhängig davon im CSS. Der wesentliche Unterschied dürfte sein, dass in der CSS-fokussierten Entwicklung keine Notwendigkeit für eine Vielzahl globaler Helperklassen besteht. Soll ein Bild bspw. nach links floaten oder einen roten Rahmen haben, erledigt man dies im passenden Modul. Bei der HTML-fokussierten Entwicklung kann es dazu kommen, eine globale Helperklasse für diesen Zweck einzusetzen. Bootstrap 4 bietet eine Fülle solcher Klassen.