CSS-Validation

Die Validation der eigenen Website wird mehr und mehr zur üblichen Qualitätsprüfung. Aber eine validierte Seite ohne qualitativen Inhalt ist eine hübsche, leere Hülle, die trotz allem leer ist.

W3C

Seitdem die modernen Browser in der Lage sind, CSS und DOCTYPE- Switching zu unterstützen,diskutieren Webworker über den Nutzen der Validation von HTML und CSS. Dieser Artikel fasst die wichtigsten Argumente zusammen, gibt Hinweise zur Benutzung des W3C-Online-Validators und erläutert die häufigsten Fehlermeldungen.

Was ist Validation?

Das Validieren von Internetseiten ist zu einem ganz aktuellen Thema geworden. Keine Seite hält den kritischen Blicken von professionellen Webseiten-Erstellern stand, wenn die Validierung vergessen wurde. Meistens werden die Seiten aber auch ohne Validierung korrekt dargestellt und wenn man die Seite mit den gängigsten Browsern (Internet Explorer, Mozilla/Firefox, Opera, Konqueror/Safari) getestet hat, dann bleibt nur die Frage: wozu soll ich meine Seiten noch validieren? Die Validierung wird von vielen als lästige Zeitverschwendung empfunden. Manche behaupten sogar, es sich das gewünschte Design mit validem Code nicht umsetzen ließe. Manchmal liegt es auch am HTML-Editor, der keinen perfekten Code erzeugt oder das CMS, dass nur „schrottigen“ Code ausgibt.
Gründe, die Validierungsphase zu überspringen, sind also Faulheit, Zeitdruck, Unvermögen, Unwissenheit oder Uneinsichtigkeit. Gegen letzteres können allerdings ein paar gute Argumente helfen…

Zukunftsorientiert

Browser werden sich in Zukunft noch enger an die (X)HTML-Standards, die vom W3C deklariert werden, halten.
Ein besonderes Augenmerk kommt dabei den Umbruch von HTML auf XHTML zu. XHTML, der Nachfolger von HTML, ist eine Untermenge von XML. XHTML-Seiten müssen „wohlgeformt“ sein, ansonsten werden sie vom Browser nicht angezeigt oder der Browser streut Fehlermeldungen in die Seite ein (was einen reichlich schlechten Eindruck macht). XHTML 1.0 ist eine Art „Hybrid“ und Bindeglied zwischen HTML und zukünftigen XHTML-Versionen. XHTML 1.0 hat die besondere Eigenschaft, zu HTML 4.01 weitestgehend rückwärtskompatibel zu sein, so dass man XHTML-Seiten auch als HTML an den Browser ausliefern kann. Alle nachfolgenden XHTML-Versionen werden keinen Rückwärtskompatibilitätsbonus mehr haben. Sie sind „echtes“ XML und werden auch dementsprechend als XML an den Browser ausgeliefert und denselben strengen Regularien unterworfen. Das Eis für invalide Seiten wird also in Zukunft eng, wenn sie gleichzeitig auf das moderne XHTML setzen wollen.

Interpretation des HTML-Codes wird nicht den Browsern überlassen

Seiten mit validen Code werden auch in Zukunft noch richtig dargestellt. Wie ein Browser mit Quellcode-Fehlern umgeht, wird ihm nach Gutdünken der Programmierer überlassen. Ebenso kann sich das Verhalten bei der Eigeninterpretation von Fehlern auch in zukünftigen Browsergenerationen ändern. Es kann sogar sein, dass ein veralteter oder proprietärer Tag einfach nicht mehr unterstützt wird.

Einmal schreiben und gut ist

Eine Seite muss nur einmal validiert werden und sie haben eine große Sicherheit, dass ihre Seite auch in Zukunft so angezeigt wird, wie sie es erstellt haben. Andernfalls müssten sie bei neuen Browsergenerationen immer wieder überprüfen, ob ihre Seite noch richtig dargestellt wird.

Mobile Endgeräte

PDAs und andere mobile Endgeräte haben auf Grund der noch geringen Leistungsfähigkeit, des kleinen Displays und den hohen Kosten für Speicher, keinen solch „fettigen“ Browser an Board, wie wir ihn vom Desktop-PC kennen. Hier sind schlanke Browserlösungen gefragt und daher haben die Browser für mobile Geräte auch nur eine rudimentäre Fehlerkorrektur für (X)HTML-Fehler.

Barrierefreiheit

Bei invaliden Code könnten Screenreader Probleme bekommen. Barrierefreiheit ist aber nicht nur ein Thema, von dem behinderte Menschen betroffen sind, sondern auch ganz normale Surfer. Sollte ein Browser aufgrund eines HTML-Fehlers also eine Seite nicht, nicht korrekt anzeigen oder sich sogar weigern, z.B. ein eingebettetes Video abzuspielen, dann ist das eben auch eine Barriere.

Interoperabilität

Valider Code ist der erste Schritt, um Seiten barrierefrei und browserunabhängig zu erstellen. Sie wissen natürlich nur zu gut, dass valider Code noch lange keine Garantie dafür ist, dass Seiten auch auf allen Browsern gleich dargestellt werden, aber die Wahrscheinlichkeit hierfür wird dramatisch erhöht. In der Praxis liegt das Problem leider viel mehr darin, dass in dem ein oder anderen Browser verschiedene Standards noch nicht implementiert wurden (oder falsch interpretiert werden, wie beim Internet Explorer).

Zeigt Professionalität

Valider Code zeigt das programmiertechnische Können seines Autor. Speziell bei Firmen, die Webseiten-Erstellung kommerziell anbieten, ist der HTML-Code ein Aushängeschild. Es wäre nur zu peinlich, wenn die Seite eines solchen Anbieters vor HTML-Fehlern strotzen würde.

Abwertung in Suchmaschinen

Gerüchte besagen, dass Suchmaschinen invaliden Code abwerten. Ich bin da etwas skeptisch, da auch viele fehlerhafte Seiten ganz oben in den Suchergebnissen mitmischen. Da diese Theorie der Suchmaschinenabwertung niemand mit Gewissheit verifizieren oder falsifizieren kann, müssen sie sich mit meiner persönlichen Meinung begnügen und die lautet, dass Suchmaschinen allenfalls schwerwiegende HTML-Fehler abstrafen.

Valider Code ist sicherer

Es besteht die theoretische Möglichkeit, dass sie mit invaliden Code einen Browser zum Absturz bringen. Die Chance, dass dies eintritt, ist denkbar gering, aber dennoch nicht aus der Luft gegriffen, wie die Nachricht „Internet Explorer am robustesten“ (vom 20.10.2004) auf Heise zeigt.

Geschwindigkeitsvorteil

Bei invaliden Code werden beim Parsen von (X)HTML-Seiten zusätzliche Routinen zur Fehlerkorrektur eingesetzt. Dies wirkt sich negativ auf die Geschwindigkeit aus. Da die Geschwindigkeitsverluste allerdings insignifikant und somit subjektiv gar nicht messbar sind, ist dieser weniger relevant.