Ein wichtiges Ziel bei der Erstellung einer Webseite ist es, validen und auch semantischen Code zu produzieren. Dies hat viele Gründe, auf die ich aber hier nicht näher eingehen will.
Der erste Schritt, dies zu erreichen, ist die Erstellung des Templates. Hier gibt es Hilfsmittel, die einen bei dieser Aufgabe unterstützen: sei es direkt bei der Erstellung in einer Entwicklungsumgebung, die das Markup live auf Fehler überprüft, oder den W3C Validator, durch den man das fertige Template jagt um abschließend zu schauen, ob man nicht doch etwas übersehen hat.
Auch beim Schreiben des CSS ist es nicht anders: Die Entwicklungswerkzeuge verhindern Tippfehler, und der W3C Validator macht die Abschlusskontrolle.
Aber was ist mit dem Inhalt, den das CMS später in das Template einfügt?
Zum Einen können auch im Inhalt fehlerhafte Tags die Validität der Seite zerstören. Sei es ein <img>-Tag, das sich nicht selbst schließt, oder ein fehlendes „summary“ Attribut in einer Daten-Tabelle. Dies lässt sich noch mit Hilfe des Validators überprüfen. Zum Anderen gibt es aber auch unerwünschtes Markup: zum Beispiel ein leeres „alt“ Attribut in einem Bild, oder ein fehlendes „title“ Attribut in einem Link. Hier hilft der Validator nicht weiter, da das Markup ja valide ist.
Außerdem gibt man die Kontrolle der Inhalte der Seite aus der Hand, sobald man das Projekt an den Kunden übergibt; sofern die Agentur nicht mit dem Einpflegen neuer Inhalte beauftragt wurde.
Ist es also möglich, den Inhalt einer Seite schnell zu überprüfen, auch auf unerwünschtes Markup – und das dauerhaft?
Ja! Die Lösung: CSS. Wir bedienen uns hierfür der Pseudoklasse :not und der Attribut-Selektoren, um unerwünschtes Markup in der Seite zu finden und optisch hervorzuheben. So können wir auf den ersten Blick feststellen, ob es Probleme gibt, und wo diese sind – ohne den Quelltext der Seite untersuchen zu müssen. Zum Markieren benutze ich hier die Eigenschaft „outline“; natürlich kann man stattdessen auch beliebige andere Eigenschaften verwenden.
Veraltete / unerwünschte Tags finden
Eine einfache Aufgabe, man stelle ein Liste zusammen, auf die man überprüfen will. In diesem Beispiel <font>, <center> und <style>. <style> ist zwar nicht veraltet, kann aber zu Layout-Problemen führen, wenn der Kunde im Inhaltsbereich Styles nachlädt.
font,
center,
style {
outline: solid 3px #FF0000;
}Veraltete / unerwünschte Attribute finden
Hier benutzen wir erstmals Attribut-Selektoren. Wir suchen nach „align“ und „style“. „style“ ist besonders problematisch, da inline-styles die Anweisungen aus dem Stylesheet überschreiben.
*[align],
*[style] {
outline: solid 3px #C00000;
}Fehlende Attribute finden
<table>-Tags brauchen in XHTML ein „summary“ Attribut, <img>-Elemente ein „alt“-Attribut. Und Links sollten immer ein „title“-Attribut haben. Wir benutzen hier die Pseudoklasse :not, mit der wir die Anweisungen in der Klammer negieren können.
img:not([alt]),
img:not([title]),
a:not([title]),
a:not([href]),
table:not([summary]) {
outline: solid 3px #A00000;
}Leere Attribute finden
Ein Klassiker: <img>-Tags mit leerem „alt“. Aber solche Attribute sind dazu da, Informationen zu tragen, und nicht nur den Validator zufrieden zu stellen!
*[alt=""],
*[title=""],
table[summary=""] {
outline: solid 3px #800000;
}Sonstiges
Die Beispiele hier sind nur einige grundsätzliche Dinge, die Möglichkeiten gehen noch viel weiter. Sei es das Auffinden von relativen URLs in Links, mit dem „beginnt-mit“-Attribut-Selektor: a:not([href^="http"]). Oder ob der erste Link in einem Menü eine geforderte Klasse hat: ul > li:first-child + a:not([class~="first"]). Oder fehlende „longdesc“ Attribute, wenn die Seite dies erfordert. Oder, oder, oder… Es lohnt sich, hier einen Blick in die CSS-Spezifikation zu werfen – und natürlich in die Dokumentation des zum Testen verwendeten Browsers.
Und wenn der Kunde neue Inhalte einpflegt?
Wenn man die Möglichkeit dieser Kontrolle auch noch nach der Übergabe des Projektes an den Kunden haben möchte, gibt es mehrere Möglichkeiten:
Dynamisch generiertes Stylesheet
Man generiert das Stylesheet dynamisch, und kann dann, abhängig zum Beispiel von einem gesetzten Parameter, die Kontroll-Regeln anhängen. Wichtig hier: Caching bei Skript-Sprachen. Dynamische Ressourcen werden häufig nicht gecacht, so dass man die vom Browser gesendeten E-Tag- oder Modified-Since-Header selbst überprüfen und gegebenenfalls einen „304 Not-Modified“ senden muss.
Dynamisch generierter <head>
Ähnlich wie letztere Methode, nur dass man im <head>-Bereich des Quellcodes das Kontroll-Stylesheet zusätzlich über ein <link>-Tag referenziert.
Nachladen per Javascript
Die Referenz zum Kontroll-Stylesheet wir nach dem Laden der Seite per Javascript in das DOM geschrieben.
User Stylesheet
Man erstellt für die URL der Seite ein User-Stylesheet. Nachteil: das Kontroll-Stylesheet muss sich dann auf dem Rechner befinden, von dem aus kontrolliert wird. Vorteil: Dafür muss kein Eingriff in die Seite vorgenommen werden.
Es lohnt sich sicherlich, mit dieser Möglichkeit der Inhalts-Kontrolle zu experimentieren. CSS ermöglicht es, visuelle Hinweise für Szenarien zu bekommen, die über die reine Validitäts-Überprüfung hinausgehen. Zudem kann man auch seine persönlichen Anforderungen überprüfen.
Hinweis zur Kompatibilität: Die hier genannten Selektoren werden von allen W3-konformen Browsern erkannt (Gecko-, Webkit-, KHTML-Engine), und von IE 7+.
Weitergehende Lektüre:
Eric Meyer hat für 24ways.org einen ausführlichen Artikel zur Kontrolle mit CSS geschrieben:
http://24ways.org/2007/diagnostic-styling
Übersicht über CSS 2.1 Selektoren bei thestyleworks.de:
http://thestyleworks.de/ref/index_se.shtml
W3C CSS 2.1 Selektoren Spezifikation:
http://www.w3.org/TR/CSS21/selector.html