9. Strikte Regeln können sinnvoll sein

Ich bin bei der Bewertung der Benamungsrichtlinien von mir ausgegangen. Diese Konzepte wurden allerdings im Rahmen sehr großer Teams entwickelt (bspw. Yahoo und Yandex), bei denen die CSS-Kompetenzen sicherlich sehr ungleich verteilt waren. In solchen Teams sind strikte Regeln ein Segen. Speziell wenn Entwickler dabei sind, die weder die Kaskade noch Spezifität kennen oder begriffen haben.

Wenn man aber allein arbeitet oder in kleinen Teams, in denen die Beteiligten Ahnung von der Materie haben, dann empfehle ich ein weniger striktes Vorgehen. Es könnten ansonsten Motivation und Effizienz darunter leiden.

Wenn Sie also allein für das CSS zuständig sind oder Ihre Kollegen ihr Handwerk auch recht gut beherrschen, dann spricht nichts dagegen, die strikten Benennungsregeln ein wenig aufzuweichen.

Sind Klassen wirklich klasse?

Alle objekt-orientierten Ansätze empfehlen den ausschliesslichen Einsatz von Klassen. Sie sollen helfen, CSS und HTML zu entkoppeln. Elemente sollen im CSS nicht mehr direkt angesprochen werden. Einzig SMACSS geht hier pragmatischer vor und beschreibt auch die Kombination von Klassen mit Element- oder Pseudoselektoren.

Ich denke, die Praxis heutiger CM-Systeme widerspricht dem radikalen Ansatz. Inhalte werden üblicherweise von Redakteuren innerhalb eines CMS in einen Editor eingegeben. Diese Inhalte können mehrere Absätze und Listen oder sogar Tabellen umfassen. Spricht man innerhalb des CSS nun nicht mehr die einzelnen Elemente an, müssten die Redakteure zwingend auch Klassennamen im WYSIWYG-Editor vergeben können, damit die Gestaltungsregeln greifen.

Dies ist ein Eingriff, den ich keinem Redakteur zumuten möchte. Dieser weiss oft mit der dahinterliegenden Technik nichts anzufangen oder fühlt sich im schlimmsten Fall zu Designexperimenten bemüssigt. Der Redakteur sollte sich einzig auf seine Inhalte konzentrieren.

Doch auch in Fällen, in denen der Frontendentwickler volle Kontrolle über das HTML besitzt, erscheint mir eine intensive Nutzung von Klassen nicht immer notwendig. Insbesondere bei einfachen Navigationen und Tabellen sehe ich keinen Gewinn darin, jedem Element eine Klasse zu geben. Nach BEM-Richtlinien sollte eine Navigation folgendermaßen ausgezeichnet werden:

 1 <ul class="navigation">
 2   <li class="navigation__item">
 3     <a href="#" class="navigation__link">Link</a>
 4   </li>
 5   <li class="navigation__item">
 6     <a href="#" class="navigation__link">Noch ein tol\
 7 ler Link</a>
 8   </li>
 9   <li class="navigation__item">
10     <a href="#" class="navigation__link">Der ist noch\
11  besser!</a>
12   </li>
13 </ul>

Das dazugehörige CSS sähe dann folgendermassen aus:

1 .navigation { /* Eigenschaften */ }
2 .navigation__item { /* Eigenschaften */ }
3 .navigation__link { /* Eigenschaften */ }

Doch eine einstufige Navigation (ohne Unternavigation!) besteht nur aus einer Liste, deren einziges direktes Kindelement das Listenelement li sein kann. Darin ist dann ein Link geschachtelt. So weit so einfach. Deshalb empfinde ich folgende Auszeichnung wesentlich sinnvoller:

 1 <ul class="navigation">
 2   <li>
 3     <a href="#">Link</a>
 4   </li>
 5   <li>
 6     <a href="#">Noch ein toller Link</a>
 7   </li>
 8   <li>
 9     <a href="#">Der ist noch besser!</a>
10   </li>
11 </ul>

Das dazugehörige CSS sähe dann so aus:

1 .navigation {/* Eigenschaften */}
2 .navigation li {/* Eigenschaften */}
3 .navigation a {/* Eigenschaften */}

In solch eng abgrenzbaren Fällen, in denen wir eine klare, nicht zu verändernde Struktur erwarten können, empfinde ich es wohltuend, Klassen im HTML einzusparen und die in CSS aus guten Gründen vorgesehenen Elementselektoren zu nutzen. Aber schon bei einer Navigation mit Subnavigation(en) nehme ich wieder Abstand von der oben beschriebenen Ausnahme. Der Nutzen von Klassen ist in solchen Momenten einfach zu hoch:

 1 <ul class="navigation">
 2   <li class="navigation__first-level-item">
 3     <a href="#" class="navigation__first-level-link">\
 4 Link</a>
 5   </li>
 6   <li class="navigation__first-level-item">
 7     <a href="#" class="navigation__first-level-link">\
 8 Noch ein toller Link</a>
 9 
10     <ul class="navigation__second-level">
11       <li class="navigation__second-level-item">
12         <a href="#" class="navigation__second-level-l\
13 ink">Link im Submenü</a>
14       </li>
15       <li class="navigation__second-level-item">
16         <a href="#" class="navigation__second-level-l\
17 ink">Noch ein Link im Submenü</a>
18       </li>
19       <li class="navigation__second-level-item">
20         <a href="#" class="navigation__second-level-l\
21 ink">Link im Submenü</a>
22       </li>
23     </ul>
24   </li>
25   <li class="navigation__first-level-item">
26     <a href="#" class="navigation__first-level-link">\
27 Der ist noch besser!</a>
28   </li>
29 </ul>

Ich sehe durchaus den Nutzen strikter Regeln. Sollten aber die Projektbeteiligten genügend CSS-Wissen besitzen, empfinde ich begründete Ausnahmen von der Regel als einen Segen. Sie vermeiden unnötig zugemülltes HTML.

Sind IDs wirklich böse?

Neben der übermässigen Nutzung von Klassen plädieren alle objektorientierten Ansätze vehement gegen die Nutzung von IDs innerhalb von CSS. Schliesslich hätten sie eine zu hohe Spezifität und könnten nicht mehrfach auf einer Seite genutzt werden. Die reine Verteufelung der Nutzung von IDs zur Gestaltung ist in meinen Augen recht sinnfrei. Aber sie schärft die Sinne für die Frage der Nützlichkeit und Notwendigkeit von IDs.

Manche CM-Systeme geben von selbst IDs aus und lassen sich dies entweder nur schwer oder gar nicht abgewöhnen. Das bedeutet für sich genommen noch nichts. Man muss die zur Verfügung gestellten IDs schliesslich nicht im CSS nutzen.

Ich sehe hingegen einen begrenzten Nutzen für IDs im CSS. In der Vergangenheit habe ich IDs oft für die konstruierenden Bereiche eines Layouts genutzt. So kann ich #header, #main, #sidebar, #footer direkt ansprechen und gestalten. Das kann sinnvoll sein, denn die korrespondierenden HTML5-Elemente header und footer können mehrfach auf einer Seite verwendet werden.

Ich stelle immer sicher, dass ich IDs nur für einmalige Zwecke nutze. Das betrifft grundsätzlich die Basisbausteine meines Layouts, es kann auch das Logo betreffen. Klassen sind und bleiben hingegen das gängigste Mittel der Wahl für die Gestaltung von Webseiten. Denn schliesslich ist es unser Bestreben, einen möglichst sparsamen CSS-Verbrauch am Ende zu haben. Das schaffen wir, wenn wir viele Regeln mehrfach verwenden können.

Die objektorientierten Ansätze plädieren gegen die Nutzung von IDs, würden dafür lieber Klassen einmalig auf einer Seite vergeben. Ich kann mich dem nicht anschliessen, finde dies eher verkrampft, als zielführend. Allerdings finde ich auch, dass es wichtigere Streitpunkte bei der Abfassung eines Stylesheets gibt, als die punktuelle Nutzung von IDs.