Teil 2:
3 Tipps, mit denen ihr euer CSS skalierbar und einfach haltet

Wer mit einem Präprozessor wie SASS oder LESS arbeitet, hat die Regel vermutlich schon gehört: Selektoren sollten nicht tiefer als in 3 Ebenen verschachtelt werden. Denn durch das vereinfachte Nesting mithilfe eines Präprozessors lassen sich wahre CSS-Selektor-Monster mit 7 oder mehr Ebenen erschaffen, die man so mit einfachem CSS wahrscheinlich nicht schreiben würde. Aber selbst wenn ihr keinen Präprozessor nutzt, solltet ihr versuchen, nicht mehr als 3 Ebenen zu verschachteln.

Früher war es durchaus üblich, die Gruppierung von Eltern- und Kindelementen durch ihre Verschachtelung zu kennzeichnen. Wenn ihr heute allerdings innerhalb eurer CSS-Anweisungen an eine Stelle wie diese kommt

.teaser { … }
.teaser .image { … }

solltet ihr prüfen, ob ihr die Verschachtelung nicht evtl. umgehen könnt, indem ihr die beiden Klassen unabhängig voneinander schreibt.

.teaser { … }
.teaser-image { … }

Durch den gemeinsamen Wortstamm lässt sich .teaser-image zweifelsohne als Kind von .teaser erkennen, allerdings sparen wir uns an dieser Stelle eine unnötige Verschachtelung.

Ganz ohne Verschachtelungen geht es aber eben doch nicht. Wenn ich an unser .teaser-image denke, werden vermutlich weitere Anweisungen folgen, z.B.:

.teaser-image { … }
.teaser-image .image_container { … }
.teaser-image img { … }

Aber immerhin bleiben wir bei den empfohlenen 3 Ebenen. Damit bleibt unser CSS übersichtlicher, wir halten den CSS Specifity Score etwas geringer und machen es uns dadurch einfacher, die Anweisungen im späteren Verlauf überschreiben oder wiederverwenden zu können.

Es gibt allerdings auch ein paar Situationen, wo Contao und die empfohlene Selektor-Verschachtelung von maximal 3 Ebenen sich in die Quere kommen.

Mein Lieblingsbeispiel in diesem Zusammenhang ist die Gestaltung einer Navigation: Wir wollen eine Hauptnavigation stylen, die aus Haupt- (.level_1) und Unterpunkten (.level_2) besteht. Um die Hauptpunkte zu gestalten, nutzen wir

.nav > ul > li {
	float: left;
	margin: 0 10px;
}

Um unsere Gestaltung auf .level_1 zu beschränken, nutzen wir die Kind-Selektor-Kombination E > F. Damit haben wir allerdings auch schon unsere 3 Ebenen für die empfohlene Verschachtelungstiefe erreicht.

Wenn wir jetzt noch den Link von .level_1 gestalten wollen würden, wären wir schon bei Ebene 4, mit :hover erreichten wir sogar Ebene 5.

.nav > ul > li > a:hover {
	color: #222;
}

Ich glaube, ich habe mittlerweile alle erdenklichen Kombinationen ausprobiert, um das irgendwie über die bereits vorhandenen Contao-Klassen zu lösen, leider vergeblich (wenn ihr doch eine Lösung kennt, immer her damit). Hier muss man sich einfach überlegen, ob man an dieser Stelle mal eine Ausnahme macht.

Mit zwei kleinen Anpassungen in der .nav_default.html5 könnten wir uns aber einen Großteil der Kindselektoren-Kombination ersparen:

Dafür ergänzen wir jedes Listenelement um eine Klasse, die das Level und den Identifier enthält, zum Beispiel .level_1-item. Nach dem gleichen Prinzip können wir auch dem Anker eine Klasse .level_1-link hinzufügen.

Und schon wären wir wieder im grünen Bereich, denn die Elemente lassen sich nun direkt ansprechen:

.nav .level_1-item { … }
.nav .level_1-link { … } 
.nav .level_1-link:hover { … } 

Wie gesagt, hier müsst ihr selbst entscheiden, ob ihr eine Anpassung am Template vornehmt und zusätzliche Klassen hinzufügt, oder ob ihr die 3 Ebenen-Regel an dieser Stelle brecht. Vielleicht kommt da aber auch noch mal etwas von den Contao-Core-Entwicklern, indem sie den Listenelementen und Links in der Navigation weitere Klassen spendieren.

Der Begriff „Modulares CSS“ ist euch wahrscheinlich schon in irgendeiner Weise über den Weg gelaufen. SMACSS, OOCSS und BEM sind nur 3 von vielen Ansätzen, mit denen sich modulares CSS schreiben lässt. Auch wenn sich die Vorgehens- und Schreibweisen unterscheiden, so verfolgen sie dennoch das gleiche Ziel.

Aber was steckt hinter dem Begriff „modulares CSS“?

Alle 3 erwähnten Ansätze – SMACSS, OOCSS und BEM – folgen 2 Prinzipien:

1. Das Layout einer Website wird in kleine, logische Module aufgeteilt. Diese werden unabhängig von ihrer Position im Layout gestylt (siehe auch Funktionellen Klassen aus Teil 1 unseres CSS-Kurses).

2. Gemeinsamkeiten zwischen einzelnen Modulen sollen erkannt und durch gemeinsame und mit einer gemeinsamen Klasse realisiert werden. Zusätzliche Klassen geben den Modulen dann ihre individuelle Gestaltung.

Ein Beispiel: Angenommen, wir haben auf einer Website 2 Navigationen. Auch wenn die beiden Navigationen sich in vielen Dingen unterscheiden – die eine ist horizontal, die andere vertikal, beide arbeiten mit unterschiedlichen Farben – so haben so dennoch ein paar Gemeinsamkeiten.

Deshalb werden die Gemeinsamkeiten einer übergeordneten Klasse zugewiesen:

.nav ul {
	list-style-type: 0;
	margin: 0;
	padding: 0; 
}

.nav li {
	margin: 0 10px;
}

Der Hauptnavigation gebe wir dann weitere, individuelle Anweisungen durch separate Klassen, zum Beispiel:

.nav-main li {
	float: left;
}

Im Idealfall schafft ihr es sogar, durch die ergänzenden Klassen nur neue Anweisungen hinzuzufügen, statt Bestehende zu überschreiben.

Das Ziel von modularem CSS ist es, eine gut pfleg- und erweiterbare Basis für die Gestaltung von Webprojekten zu schaffen. Durch die Struktur der CSS-Anweisungen lassen sich die Klassen gut miteinander kombinieren und eine Vielzahl von Gestaltungssituationen abdecken. Gleichzeitig folgt die Schreibweise dem DRY-Prinzip.

DRY steht für Don’t Repeat Yourself und bezieht sich auf die Art, wie man CSS schreiben sollte. Anfangs wollte der Erfinder Jeremy Clarke lediglich darauf hinaus, dass man sich wiederholende CSS-Anweisungen gruppieren sollte.

Statt

h1 {
	font-family: Open Sans;
	color: #222;
	margin-bottom: 24px;
	font-size: 48px;
}

h2 {
	font-family: 'Open Sans';
	color: #222;
	margin-bottom: 24px;
	font-size: 36px;
}

h3 {
	font-family: 'Open Sans';
	[…]
}

besser

h1, h2, h3 {
	font-family: Open Sans;
	color: #222;
	margin-bottom: 24px;
}

h1 {
	font-size: 48px;
}

h2 {
	font-size: 36px;
}

h3 {
	[…]
}

Mittlerweile geht man aber noch einen Schritt weiter. Statt lediglich die Klassen mit gleichen CSS-Anweisungen zu gruppieren, versucht man nun für alle Elemente mit gleichen Eigenschaften eine gemeinsame Klasse festzulegen und sie den Modulen zuzuordnen. Dadurch lassen sich, gerade bei umfangreicheren Projekten, weitere Zeilen CSS sparen.

Natürlich hat modulares CSS auch seine Nachteile. Dadurch, dass das Erscheinungsbild eines Moduls nicht mehr von einer Klasse, sondern mitunter von 2, 3 oder mehr Klassen bestimmt wird, wird es auch im HTML-Code etwas voller. War es früher eher unüblich mehrere Klassen für ein Element zu benutzen und zeugte von schlechtem Stil, sieht es heute genau umgekehrt aus. Lieber ein paar Klassen mehr, dafür aber deutlich weniger CSS schreiben.

Das führt leider in letzter Konsequenz auch dazu, dass die Rückverfolgung von Darstellungsfehlern im Web-Inspector oder Firebug durch das Styling mit mehreren Klassen nicht mehr ganz so leicht ist.