Seit geraumer Zeit arbeiten ich viel bei Kunden vor Ort. Aktuell häufig bei einem Kunden am Hamburger Fischmarkt, Große Elbstraße, mit Aussicht auf die Elbe. Im Laufe des Vormittags tappere ich von meinem Büro im Belle-Viertel über die Schanze den Straßenzug Bernstorffstraße/Kleine Freiheit/Pepernmölenbek bis zur Elbe runter. Mitsamt Fußweg zum Büro und Nachhause-Weg kommen da täglich knapp anderthalb Stunden Wegstrecke zusammen. Folgerichtig habe ich meinen Podcastkreis erweitert, zum Beispiel um SWSX-Vorträge

Gleich der erste Vortrag “CSS for Grown Ups: Maturing Best Practices” von Andy Hume erwies sich als Volltreffer. Audio (MP3, ca 58min), Slides (Speakerdeck)

Hume stellt natürlich gewachsene Paradigmen der Web Standards-Bewegung in Frage, insbesondere die bisher propagierte Trennung zwischen ausschließlich semantischen HTML-Markup und ihre Verdrahtung mit CSS.

Von dem Gedanken “das HTML-Markup hat keinerlei Informationen über das Design zu besitzen” geht Hume schnell weg und spricht vom Markup als eine Art “API” für die Gestaltung per CSS. Das Andocken von Gestaltung z.B. an einem H2-Element sei aber weder semantisch, noch flexibel. H2 kann z.B. innerhalb einer Website im Kontext “Homepage” eine Artikel-Headline darstellen, aber im Kontext “Artikel-Seite” die Subheadline des Artikels sein, während dann dort die Headline als H1 ausgezeichnet ist.

Für denjenigen der im CSS-Code rumwühlt, erschließt sich durch das reine Markup nicht, welche Bedeutung Elemente wie H1 oder H2 haben. Noch schlimmer: das CSS eskaliert und wird komplexer, weil es für unterschiedliche Kontexte unterschiedliche Elemente berücksichtigen muss:

#page-home H2,
#page-single H1 {
	font-size: 36px;
}

Wäre es aus CSS-zentrischer Sicht nicht semantischer, das CSS nicht an Elementen, sondern an Klassen anzuhängen?

<h1 class="headline">Suppenwürfel machen Krebs!</h1>

.headline {
	font-size: 36px;
}

Diese Parallel-Existenz von Semantik mit HTML-Element und Sematik mit CSS-Klassen war bislang verpönt und ein Bruch der klaren Trennung von Markup und Gestaltung.

Die Zeiten haben sich aber geändert. Wir reden nicht mehr von Firmen-Websites die sich in zehn HTML-Seiten abfrühstücken lassen, wie einst 2004, sondern von komplexen, datenbank-gesteuerten Sites und Applikationen, deren CSS-Code locker eine vierstellige Zahl von Zeilen umfasst.

Wird das CSS nicht dadurch flexibler und sogar semantischer wenn beschreibende Klassen verwendet werden wie

<a href="#" class="button button--large is-disabled">Remove</a>?

(Man beachte dass die “Beschreibung” hier ebenfalls semantischen Wert hat und nicht wie “button--100px” oder “button--green” aufgebaut ist!)

Es hebe derjenige die Hand, der noch nie eine beschreibende CSS-Klasse wie “button” verwendet hat…

Trotzdem: ich fand dies in dieser Konsequenz gewöhnungsbedürftig und bin schlichtweg an der Grenze der Überforderung, wenn Hume dann auch noch vorschlägt, HTML-Elemente über Javascript als Trigger für CSS-Klassen zu nehmen:

<div data-squery="min-width:400px=wide max-width:10em=small">

Hume hat dazu selector-queries geschrieben, die das obige Attribut “data-squery” auswerten: wenn der DIV-Container schmaler als 10em ist, bekommt er die Klasse small. Ist er breiter als 400px, bekommt er die Klasse wide. Ansonsten bleibt die Klasse leer (was nicht immer das Oberoberoptimalste als Fallback für Javascript-lose Clients ist).

Gefiel mir auf Anhieb nicht wirklich, aber je länger ich darüber nachdenke, ist dies für viele Websites vielleicht sogar der richtige Schritt um CSS-Module voneinander unabhängiger zu machen, denn Media-Queries in CSS arten quick in verschachtelten Spaghetti-Code aus und kommen in Sachen “Responsive Images” schnell am Ende ihres Lateins.

Ein zweiter zentraler Punkt des Vortrages von Hume ist die Strukturierung von CSS in möglichst unabhängigen Modulen: “Don’t style pages, style modules.”

Ein Qualitätsmaßstab für Module ist ihre Unabhängigkeit von CSS-Code außerhalb des eigentlichen Module-CSS und ließe sich testen, indem man die Module in anderen Kontexten (Seitenleiste vs Content-Bereich) oder in der als Website angelegten Dokumentation ablegt.

Für den Workflow ist dies an zwei Punkten ein weitreichender Move. Es ist ab einem bestimmten Punkt das Verlassen der gewohnten “Top-Down”-Produktion einer Website und die komplette Abstraktion eines Moduls von ihrem zukünftigen Bestimmungsort.

Es ergibt sich daraus die interessante Frage der Dateiorganisation innerhalb eines Projektes. Auch hier ist CSS noch auf der Suche nach Best Practice. Hume schlägt drei Kategorien von Stylesheets vor, durch die eine Aufgabenteilung bewirkt wird, die die Übersichtlichkeit erhöhen soll und damit den Code pflegbarer machen soll – auch hinsichtlich des Recyclings von Modulen.

• Base – Styles für Elemente, das Fundament der Website für site-weite Eigenschaften wie Link-Farben, Schriften, Schriftgrößen
• Module – eigenständige Module wie “Einklinke”, “Link-Box”
• Layout – Layout der Seite wie z.B. Spalten

Es gibt andere Versuche der Strukturierungen für CSS wie OOCSS, BEM oder SMACSS.

SMACSS definiert fünf Kategorien von Stylesheets:

• Base – Stellt die Default-Gestalltung für HTML-Elemente, Attribute und Pseude-Classes dar.
• Layout – Grober Seitenaufbau über die Ansprache von single-class- oder id-Selektoren.
• Moduls – Wie bei Hume handelt es sich um wiederverwendbare Module wie Poduktlisten, die über classes angesprochen werden.
• State – Beschreibt die Zustände von Layouts oder Modulen wie “enabled”, “hidden”, auch in Kontexten wie für Mobile-Clients etc…
• Theme – Selbsterklärend.

Aktuell sitze ich an einer ähnlichen Struktur (SASS-basierend: Values – Mixins – Generic – Elements – Modules) – allerdings für eine hoffnungslos kleine Website und es fühlt sich nicht korrekt an für so eine kleine Website zwischen fünf unterschiedlichen SASS-Dateien zu springen.

Die Suche nach Best Practice wird auf Jahre nicht vorbei sein und bis dahin noch in viele Sackgassen gegangen werden, noch viel Overhead produziert und noch viele Kundenprojekte als Testlabor dienen.