Kontextuelle Selektoren ermöglichen es, im HTML-Quelltext einer Seite auf das Setzen von id- oder class-Attributen zu verzichten und stattdessen über die Struktur des Dokuments auf bestimmte Elemente zuzugreifen und diese zu formatieren. Dadurch wird der Code einfacher, Arbeit gespart und insgesamt intelligenter vorgegangen.
In der Praxis ist es oft zu beobachten: Jeder Bereich und jedes Element, das ein bestimmtes Aussehen erhalten soll, wird auch gerne sofort mit einer Klasse versehen, heißt, man setzt im betroffenen Markup rasch mal ein class-Attribut, welches als CSS-Selektor herhalten soll, und nimmt dann die Justierung der Darstellung vor. Manchen Autoren wird dieses Problem bereits bekannt vorkommen, wenn sie daran denken, wie oft allein schon ein einfacher Elementselektor (à la h1) reicht, ohne dass man gleich einen eindeutigen Bezeichner oder eine Klasse wählen muss — noch viel häufiger jedoch wird es verpasst, auch aus der Seitenstruktur und damit dem Kontext Nutzen zu ziehen.
Hier ein einfaches Beispiel, ohne großartiges Suchen auf der Webseite von Yahoo entdeckt:
<div class=ct> <div class=u></div> <div class=u></div> <div class=u></div> <div class=u></div> </div>
Der Inhalt der „u“-Container wurde der Einfachheit halber ausgeblendet, und auf einen Kommentar bzgl. der nicht in Anführungszeichen gesetzten Attributswerte wird an dieser Stelle verzichtet. Es stellt sich vielmehr die Frage, ob die Klasse „u“ wirklich notwendig ist — einen semantischen Sinn hat sie offensichtlich nicht. Auch IDs und Klassennamen verfügen idealerweise über eine Bedeutung, wie es z.B. die Klasse „error“ wunderbar verdeutlicht.
So einfach kann man die dortigen Klassen nicht entfernen, was allerdings durch die prinzipiell notwendigen zusätzlichen Anpassungen egalisiert wird, denn in erster Linie würde man einem solchen Fall Listen und keine bedeutungsleeren div-Elemente gebrauchen. Wie sich dieser Code grundsätzlich vereinfachen lässt, liegt nahe. Hier nun mit einem in Anführungszeichen gesetzten Attributswert „ct“ sowie eingerückten Kindelementen.
<div class="ct"> <div></div> <div></div> <div></div> <div></div> </div>
Im Stylesheet selbst benutzt man jetzt anstelle des Selektors div.u oder .u einfach .ct div — oder, wenn der Außencontainer nur für analoge Fälle gebraucht wird, lediglich div div, wobei man sich der Klasse „ct“ dann idealerweise gleich ganz entledigt, class=“ct“ also entfernt. Der Code ist eindeutig einfacher geworden, vergleicht man die beiden Codeausschnitte, und die Realisierung ist flexibel — in einem Container „example“ könnte man wiederum div-Elemente verwenden, denen man dann via .example div andere Eigenschaften zuweist.
Grundsätzlich bietet sich der Gebrauch von kontextuellen bzw. „Nachkommenselektoren“ (von kontextuellen Selektoren ist offiziell nur in CSS 1 die Rede, ab CSS 2 heissen diese „descendant selectors„) immer dann an, wenn Elemente oder bestimmte Instanzen eines Elements (denn natürlich können z.B. auch Attributselektoren in einen Kontext gebracht werden) in mehr als einem strukturellen Zusammenhang verwendet werden und dabei eine unterschiedliche Formatierung erhalten sollen — denn sonst würde ein alleinstehender Selektor genügen.
Das Vorgehen kann zudem verfeinert werden, indem man absichtlich und gezielt bedeutungsleeres (also nicht semantisches) Markup wie div- oder span-Elemente gebraucht, um in seinen Stylesheets nur Element- und kontextuelle Selektoren zu verwenden, was das HTML noch schlanker werden lässt. Der folgende Quelltext zum Beispiel erlaubt es, zwei ganz unterschiedliche Darstellungen einer Liste auf einer Webseite zu verwenden, ohne dass irgendein zusätzliches Attribut gebraucht werden muss:
<ul> <li>Punkt 1</li> <li>Punkt 2</li> <li>Punkt 3</li> </ul> <div> <ul> <li>Punkt A</li> <li>Punkt B</li> <li>Punkt C</li> </ul> </div>
Im darauf angewendeten Stylesheet reichen dann selbstredend die Selektoren ul und div ul, um dem Autor alle Freiheit zu schenken.
Mit ein wenig Gespür können HTML-Code und Stylesheets also leicht vereinfacht werden, und es kann allein über den Kontext gezaubert werden. Doch manchmal sind auch IDs und Klassen sehr wohl nützlich, ab und an gar unverzichtbar.
