1. Vorgeplänkel

Seit einigen Jahren halte ich immer wieder Vorträge und gebe Schulungen, um meine Ideen modularer Webentwicklung zu verbreiten. So einmalig und besonders sind diese Ideen gar nicht. Insbesondere die Modularisierung des HTML dürfte heute implizit gang und gäbe sein. Ausser bei den meisten Wordpress-Projekten, da dieses CMS seitenbasiert funktioniert. Doch es besteht ein Unterschied zwischen der Modularisierung durch Templates innerhalb eines CMS und dem dazugehörigen modularen CSS. Während das HTML der Webseiten üblicherweise in kleine Schnipsel (Templates) aufgeteilt werden, ist das CSS meist nicht so optimal geschrieben.

Auf meinen Heimreisen begann ich, das eben Gelehrte in Worte zu fassen. Dabei habe ich über die Jahre an mir selber eine Veränderung in der Haltung zum Thema festgestellt. Diese Webseite / dieses Büchlein ist nun die Quintessenz meiner Schulungen und Überlegungen. Gut möglich, dass der Inhalt in Zukunft erweitert wird, denn das Thema ist in Bewegung. Angetrieben von Styleguides und Pattern Libraries beschäftigen sich heute immer mehr Entwickler mit vernünftigem Code für CSS und HTML.

Für das bessere Verständnis der Inhalte ist es unerlässlich, zumindest zwei Grundprinzipien von CSS verstanden zu haben: die Kaskade und die Spezifität.

Die Kaskade

Das “C” in “CSS” steht für “Cascading”, also die Kaskade. “Wer zuletzt kommt, malt zuerst” kann man das Prinzip der Kaskade zusammenfassen. Eine Regel überschreibt eine gleichwertige Regel, wenn sie nach dieser im Code kommt. Nehmen wir dieses simple Beispiel:

 1 p {
 2 	color: red;
 3 	margin-bottom: 10px;
 4 }
 5 
 6 /* Hier kommen einige Zeilen CSS-Code. */
 7 
 8 p {
 9 color: black;
10 }

Da in der zweiten Regel eine Farbe definiert wurde, überschreibt sie die Farbe der ersten Regel. Alle Absätze werden also nun mit schwarzem Text formatiert. Das margin-bottom bleibt unangetastet, denn es wurde in der zweiten Regel nicht erwähnt. Diese Technik ist ein wichtiger und integraler Bestandteil von CSS. Die Kaskade kann nur durch eine unterschiedliche Spezifität ausgehebelt werden.

Die Spezifität

Die Spezifität ist das zweite wichtige Grundprinzip von CSS. Sie ist die Antwort auf die Frage, wie allgemein oder wie spezifisch eine Regel ist. Die oben gesehene Regel für einen Absatz ist sehr allgemein:

1 p {
2 	color: black;
3 }

Damit werden alle Absätze angesprochen. Weniger allgemein ist diese Regel:

1 article p {
2 	color: blue;
3 }

Diese Regel gilt nur für alle Absätze, die sich in einem article-Element befinden. Die Regel wendet sich also spezifisch an Absätze in einem bestimmten Kontext. Gleiches kann man mit Klassen machen oder einer Kombination Klassen und Elementen:

1 .box {
2     margin: 10px;
3 }
4 
5 article.box {
6     margin: 20px;
7 }

Klassen können an jedes Element gehängt werden. Deshalb ist die zweite Regel spezifischer als die erste, denn sie konkretisiert die Anwendung der Klasse: die Klasse .box wird an einem article-Element genutzt, nicht an einem div oder einem anderen Element.

Je spezifischer eine Regel ist, desto höher ist ihr Wert, der in Zahlen ausgedrückt werden kann. Und durch diese Spezifität wird das Prinzip der Kaskade durchbrochen:

1 article p {
2 	color: blue;
3 }
4 
5 p {
6 	color: black;
7 }

Obwohl in der zweiten Regel alle Absätze eine schwarze Schrift bekommen, bleiben alle Absätze innerhalb eines article-Elements blau. Die dazugehörige Regel ist spezifischer, weshalb die Kaskade nicht zieht.

Richtiger Umgang mit diesen Prinzipien

Kaskade und Spezifität werden uns immer wieder begegnen. Sie sind der Schlüssel für effiziente, wartbare und verständliche CSS-Dateien. Entwickler, die entweder diese Prinzipien nicht kennen oder sie nicht beherrschen, werden unglücklich mit der Arbeit an CSS-Dateien. Gerne wird dann der Vorwurf erhoben, CSS sei “kaputt”. Dem ist aber nicht so. Das Probelm ist nicht CSS, es ist unvollständiges Wissen der Entwickler über die Funktionsweise der Sprache. Dabei steht ganz oben die Erkenntnis, dass CSS keine Programmiersprache ist und sich deshab auch nicht deren Prinzipien und Denkmustern unterwerfen muss.

Es gibt drei Faktoren für schlecht wartbares CSS. Oft wird es von Entwicklern geschrieben, denen vertieftes CSS-Wissen fehlt.

Der erste Faktor ist die generell überspezifische Formulierung einer Regel, wie in diesen Beispielen:

 1 html.ng-scope body.ui-layout-container div#dialog.dia\
 2 log-frame section.dialog-frame-body section.content s\
 3 ection#dialogBody form#balanceOptionsForm.stform fiel\
 4 dset#morebalanceoptions ul li label { 
 5     /* .... */
 6 }
 7 
 8 html body div.project-body section.project-main #proj\
 9 ect-content .project-service_bar { 
10     /* .... */
11 }

Hier wird im Prinzip das DOM abgebildet. Das ist zum einen unnötig und zum anderen gilt diese Regel wahrscheinlich nur in diesem einen Projekt. Doch dazu später mehr.

Ein zweiter Faktor ist eine hohe Anzahl der !important-Zusätze in Regeln. In Einzelfällen kann ein !important zu rechtfertigen und zweckmässig sein. Doch spätestens bei 10 Stück in einem Stylesheet ist die Grenze des Sinnvollen erreicht. Ein !important wird gerne dann genutzt, wenn der betreffende Entwickler keinen Überblick (mehr) über die bisher genutzten Regeln hat. Das kann an einem unsortierten CSS, aber auch an mangelnder CSS-Kompetenz liegen. Ein !important ist eine schnelle und trügerische Lösung.

Und als Drittes: Am Ende des Stylesheets sammeln sich gerne im Laufe des Projektes wild durcheinander Regeln, die andere Regeln überschreiben sollen. Oft passiert dies durch eine höhere Spezifität, indem mehr DOM-Knoten vor die eigentliche Regel geschrieben werden (siehe Faktor 1). Gerne wird auch das eben erwähnte “!important” zu Hilfe genommen.

All dies wollen wir in Zukunft hinter uns lassen. Steigen wir also ein, in die modulare Webentwicklung!