Es gibt kein semantisches CSS

Es gibt seit einiger Zeit immer wieder Blog-Artikel, die sich mit der Qualität unserer Arbeit im Frontend auseinandersetzen. Sie thematisieren dabei den Aufbau unseres CSS, die Benamung von Klassen oder die Verwendung von IDs. Es sind meist interessante, bedenkenswerte Artikel. Häufig stolpere ich dabei in den Artikeln oder in den Kommentaren über die Wendung „semantisches CSS“. Sorry Leute, das gibt es nicht!

Semantik wird durch HTML-Elemente repräsentiert. Klassen existieren als HTML-Attribute, damit man zusätzliche Ansatzpunkte schafft, die man bspw. für die Gestaltung einer Webseite nutzen kann. Mikroformate nutzen Klassen als Vehikel, um Semantik zu transportieren. Das ist mehr oder minder ein Hack. Es ist eine erweiterte Nutzung der Klassen.

Klassen sind ganz bewusst Teile der Gestaltung, nicht der Semantik. Wir sprechen besser nicht mehr von semantischen, sondern von pflegbaren Klassen.

Es gibt keinen falschen Klassennamen

Die Benennung einer Klasse nach visuellen Kriterien ist nicht falsch, sie ist höchstens unpraktisch. Eine Klasse .rot steht in der Gefahr, dass sie im Laufe des Projektes oder in einem Folgeprojekt zum Transport von Blau oder Schwarz genutzt 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 durch ihre inhaltliche Bedeutung.

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

Klassen werden von Menschen für Menschen geschrieben. Weder eine Suchmaschine, noch ein Browser, noch ein Screenreader haben einen Nutzen von der Verwendung von Klassen. Deshalb sollten Klassennamen von Entwicklern verstanden werden, damit sie sie problemlos nutzen können.

Durch die Idee der semantischen Klassen wird leider der Fokus von einer guten Struktur entfernt. Nicht mehr das semantische HTML erscheint wichtig, sondern die Klassennamen. Das sollte nicht geschehen. Eine gesunde, sinnvolle Struktur ist die Basis eines guten Frontends. Die verwendeten Klassennamen sind dabei nebensächlich, Hauptsache sie sind pflegbar.

3 Kommentare

  1. Guter Post. Ich dachte schon zuweilen, ich sei die einzige, die das so sieht.

  2. Ich hoffe, ich werde jetzt nicht falsch verstanden, aber

    > Durch die Idee der semantischen Klassen wird leider der Fokus
    > von einer guten Struktur entfernt. Nicht mehr das semantische
    > HTML erscheint wichtig, sondern die Klassennamen.

    Spätestens hier klingt der Designer durch, denn eigentlich ist die Grundannahme schon falsch. Die geht nämlich offenbar davon aus, dass „class“ und „id“ existieren, um Designern und Frontend-Entwickler das Leben zu erleichtern. In Wirklichkeit interessiert sich HTML aber gar nicht für CSS und JS, das kommt erst im Browser. Stattdessen gilt, dass „id“ ein Objekt (bei HTML: Ein Knoten im DOM) identifiziert und „class“ ein Object einer Klasse im Sinne der Mengenlehre zuordnet.

    In diesem Sinne ist

    > Klassen sind ganz bewusst Teile der Gestaltung, nicht der Semantik.

    Schlicht falsch.

    Ich lass mal aussen vor, dass die strenge Semantik in der Praxis häufig unpraktisch ist, was es allerdings nicht richtiger macht sie zu ignorieren, oder gar für „gewollt“ zu erklären 🙂

    • @KingCrunch: Einen Designer hat mich ja noch niemand geschimpft 😉

      Die Beschreibung der Eigenart von ID und Klasse sind korrekt. Aber sie haben doch einen Nutzen, sonst wären sie nicht da, oder? Eine ID ist dafür da, um ein einzelnes Element eines Dokumentes zu indentifizieren. Eine Klasse identifiziert eine beliebige Menge.

      Damit kann ich dann etwas anstellen. Entweder mittels CSS oder JS. Was ich über diesen Weg aber keineswegs transportieren kann, ist Bedeutung. Das ist anderen Attributen vorbehalten, wie „rel“ oder „aria-labeledby“. Klassen und IDs setzen nur Ankerpunkte, an denen CSS oder JS oder ein Parser bspw. für Mikroformate andocken kann.