3. Mit CSS gestalten

Mit CSS gestalten wir HTML-Seiten. Es stehen uns hierbei mehrere unterschiedliche Möglichkeiten offen und drei unterschiedliche Wege, CSS auf HTML einwirken zu lassen.

Wir können CSS-Regeln über Elemente, Klassen, IDs oder spezielle Selektoren (und jede beliebige Kombination daraus) auf HTML-Elemente einwirken lassen. Wir können das CSS in den Kopf der HTML-Seite schreiben, direkt an das Element oder in ein externes Stylesheet. Wir können CSS sogar über JavaScript schreiben, auch hier über die drei eben beschriebenen Wege.

Alle diese Möglichkeiten und Wege sind primär wertfrei zu betrachten. Sie sind weder falsch noch richtig. Leider wollen uns immer wieder Entwickler einreden, es gäbe gute und schlechte Arten, CSS zu schreiben und zu implementieren. Da die Standards viele Wege offen lassen, geht ein einfaches “Gut-Böse”-Schema an der Realität vorbei. Wir sollten eher von praktischen oder unpraktischen Methoden sprechen. Das sind jedoch situationsabhängige Eigenschaften. Man kann sie nicht abstrahieren und allgemeingültig machen.

Die berühmten “Best Practices”

Welchen Weg und welche Methode wir auch wählen, wir haben es immer mit Vor- und Nachteilen zu tun. Im Allgemeinen ist es am Sinnvollsten, Styles in ein externes Stylesheet zu schreiben. So muss man nur eine CSS-Datei pflegen und kann diese mit unendlich vielen HTML-Dateien verbinden.

Aber nehmen wir einmal an, in einem Modul - beispielsweise einer Teaserbox - müssen immer wieder individuelle Hintergrundbilder eingebunden werden. Diese Hintergrundbilder können nicht im Vorhinein definiert werden. Es handelt sich hierbei um eine redaktionelle Arbeit. Doch niemand möchte einem Redakteur Zugriff auf das CSS geben. Also bietet sich die Arbeit mit einem Inline-Style an. Diese Ausnahme von der Regel ist sinnvoll. Ein pauschales Verbot der Nutzung von Inline-Styles wäre demnach kontraproduktiv.

Yahoo schreibt auf der jeweiligen Startseite große Teile des CSS direkt in den Head, weil die Styles so schneller geladen sind, als über eine externe Datei. Vor einigen Jahren schrieben sie sogar alle CSS-Regeln auf der Startseite in den Head - auch aus Performancegründen. Denn sie hatten durch Analysen festgestellt, dass die meisten Besucher mit geleertem Cache vorbeikamen. Der positive Effekt externer CSS-Dateien war also dahin. Die Vermeidung eines Requests trug offenbar zum schnellen Laden der Startseite bei. Heute spricht man in diesem Zusammenhang von “Critical CSS” und “Above the fold”.

Das mag uns auf den ersten Blick nicht gefallen, es mag sich falsch anfühlen. Aber es zeigt, dass wir ein Problem mit “Best Practices” haben. Denn was die meisten Entwickler als ebensolche verstehen, mag in Einzelfällen problematisch sein. In Einzelfällen mögen “Bad Practices” die “Best Practices” sein. Wichtig ist, dass wir uns ernsthaft mit unseren Rahmenbedingungen auseinandersetzen und über das effektive Handling in unserem Projekt nachdenken.

Aufpassen bei Verboten

Wie wir später sehen werden, arbeiten Coderichtlinien gerne mit Verboten. Die Verbote treffen dabei auch Techniken, die sich bewusst im CSS-Sprachschatz befinden. Die einseitige Fokussierung auf Klassen und die Negierung anderer Selektoren erschwert m.E. die Arbeit unnötig. Einen ersten Absatz kann man prima mit :first-child selektieren und dann gestalten. Dafür muss weder ein Redakteur im Editor eine Klasse zuweisen noch eine besondere Logik im Backend programmiert werden, um eben jenem ersten Absatz eine spezielle Klasse zuzuweisen.

Auch die Markierung besonderer Linkarten wie ein verlinktes PDF, Word-Dokument oder der Verweis auf eine andere Domain können mit einfachen CSS-Attributselektoren passend gestaltet werden. Weder ein Redakteur, noch ein Backend-Entwickler werden benötigt.

Deshalb plädiere ich dafür, Vorsicht bei Verboten walten zu lassen. Es kann sein, dass man sich durch deren Befolgung unnötige Probleme ins Projekt holt.

Man muss diese Verbote aus dem Kontext heraus verstehen. Alle diese objektorientierten Ansätze wurden unter dem Eindruck großer Teams erdacht. In diesen Teams waren zudem die Frontend-Kenntnisse nicht gleichmässig gut verteilt. Sollten Sie also in einem Team mit Entwicklern arbeiten, die kaum Ahnung von CSS haben, dann sind restriktive Regeln eine große Hilfe. Sie geben Orientierung und Sicherheit. Sollten Sie aber mit richtig guten Frontendentwicklern arbeiten, verschlechtern Sie evtl. durch allzu große Restriktionen nur das Arbeitsklima.

Wenn der Standard Ihnen Techniken an die Hand gibt, müssen Sie sie nicht nutzen. Sie sollten sich aber auch bewusst sein, dass diese Techniken nicht per se falsch sein können. Es kommt auf den Kontext und den konkreten Anwendungsfall an.