5. Jedes Modul ist eine eigene Welt

Damit wir im Frontend wirklich modular entwickeln, müssen wir auch die entstehenden Module als eigene Einheiten verstehen. Im CSS beginnen die Selektoren dementsprechend mit dem Modul selber oder einem seiner Bestandteile. Sie sollten immer verhindern, einen Teil des umgebenden DOM mit in die Selektoren zu schreiben.

 1 /* --------- So macht man das! ------------ */
 2 /* Das Modul steht für sich. */
 3 
 4 .videowrapper {
 5     /*  Eigenschaften */
 6 }
 7 .videowrapper iframe {
 8     /* Eigenschaften */
 9 }
10 
11 
12 /* ----------- keine gute Idee! ------------ */
13 /* Was, wenn der Videowrapper demnächst in einem
14       anders benamten Container stecken sollte? */
15 
16 .maincnt .videowrapper {
17     /*  Eigenschaften */
18 }
19 .maincnt .videowrapper iframe {
20     /* Eigenschaften */
21 }

Die zweite hier vorgestellte Vorgehensweise ist sehr stark verbreitet. Dabei wird der Selektor meist noch viel mehr aufgebläht. Manchmal wird fast das gesamte DOM abgebildet. Das hat zwei Nachteile:

1. Die Spezifität wird (stark) erhöht, sodass es immer schwerer wird, Abweichungen zu definieren. Selbst die Modifikatorklassen würden einen ähnlich komplexen Selektor benötigen. Oder man resigniert und verteilt “!important”.
2. Die Abbildung von Selektoren vor dem Modul macht das Modul schwer transportabel. Man könnte es in einem anderen Projekt nur dann nutzen, wenn auch dort eine gleich benannte, ähnlich aussehende Struktur existierte. Sollte sich die Struktur der Webseite zwischen Planung und Endversion oder zwischen zwei Projekten grundlegend ändern, ist die Wahrscheinlichkeit hoch, dass solche Selektoren nicht mehr ziehen werden.

Jedes Modul sollte für sich selbst stehen. Wenn dem so ist, dann kann man prinzipiell einen Produktteaser in den Header oder Footer platzieren und er sieht noch immer wie gewünscht aus. Nicht, dass dieses Vorgehen sinnvoll wäre, es wäre aber der ultimative Test.

Erfolgreiche UI-Frameworks wie Bootstrap oder Foundation funktionieren exakt so. Auf den jeweiligen Übersichten stehen bspw. mehrere Navigationen untereinander, die von Formularen und Tabellen gefolgt werden können. Alle sind aus einem etwaigen Zusammenhang gerissen und sehen trotzdem wie gewünscht aus.

Machen Sie den Test mit Ihrem eigenen Projekt: Erstellen Sie eine Datei ohne den üblichen Rahmen. Nutzen Sie ein vollkommen neues Grid, das Sie in Ihrem Projekt nicht nutzen und platzieren Sie dann mehr oder minder willkürlich die Module Ihrer Webseite auf dieser Testseite. Sie werden nun auf einen Blick sehen, welche Module eine bestimmte Struktur benötigen, damit sie wie gewünscht aussehen. Mit dem CSS dieser Module beginnen Sie dann die Überarbeitung Ihres Projektes.

Module identifizieren

Bevor wir Module gestalten, müssen wir sie erst einmal identifizieren. Dafür nehmen wir uns das Design in all seinen Ausprägungen und schauen zuerst nach einmalig vorkommenden Seitenbestandteilen. Normalerweise sind dies alle Elemente des Headers und des Footers. Sodann schauen wir nach Seitenbestandteilen, die identisch oder ähnlich mehrfach vorkommen. Die Ähnlichkeit ist dabei durchaus wichtig. Denn wenn es neben einem Container mit einer einfachen Linkliste auch einen gibt, bei dem neben den Links auch Icons abgebildet sind, so rechtfertigt diese eine Abweichung nicht, daraus ein eigenständiges Modul zu machen und damit viel duplizierten Code zu schreiben.

Stattdessen sollte die Abweichung über eine oder mehrere ergänzende Klassen geregelt werden. Später taucht dieser Ansatz als “Modifikator” noch einmal auf. Die beiden folgenden Screenshots sind eine starke Simplifizierung, aber sie weisen darauf hin, dass nur der Wechsel des Aufzählungszeichens kein vollkommen neues Modul kreiert. Es handelt sich in beiden Fällen um eine Liste. Die Sterne als Aufzählungszeichen sind entweder der Standard oder die Abweichung. Aber sie rechtfertigen nicht, ein neues Modul mit umfangreichen Styleanweisungen zu erstellen.

Zur Orientierung, welche Module existieren, empfehle ich, die Designs auszudrucken und im wörtlichen Sinne auseinanderzuschneiden. In kleinen Schnipseln auf einem großen Tisch oder an der Wand klebend können Sie kleine Haufen und Inseln bilden. Sie identifizieren dadurch viel schneller Ähnlichkeiten. Ein Computermonitor schränkt durch seinen zur Verfügung stehenden Platz sehr ein.

Am Namen sollst Du sie erkennen

Klassen zu benennen ist nicht einfach. Abseits der später besprochenen Methodiken, die ihre eigenen Ideen haben, bleibt die grundsätzliche Frage der Klassennamen. Aus der Praxis gebe ich folgende Regeln als Ratschläge:

1. Englische Namen sind deutschen vorzuziehen, denn sollte man Hilfe bspw. in Stackoverflow benötigen oder der Templatesatz zur Weiterbearbeitung ins Ausland gehen, helfen deutsche Klassennamen nicht weiter.
2. Die Klassennamen sollten nicht eng an die Optik gekoppelt sein. Eine Klasse .blue ist nur solange praktisch, bis man die damit verbundene Gestaltung auf Kunden- oder Designerwunsch in rot ändern muss. Dann gibt die Klasse .blue auf einmal rote Ergebnisse.
3. Zu enge inhaltliche Verknüpfungen sind aber auch nicht praktisch, denn eine .sponsortable kann prima auch für eine Tabelle genutzt werden, in der Kundenlogos stehen. .imagetable wäre evtl. eine bessere Wahl. Der Name sollte also eine gesunde Balance zwischen Abstraktion und inhaltlicher Beschreibung wahren. Das ist nicht einfach, aber ein erreichbares Ziel.