Skip to main content

Zwischen Ordnungssinn und Validierungszwang ...

... liegt der sprichwörtliche schmale Grat. Muss eine Website gegen Standard XY validieren? Und wer hat eigentlich etwas davon? Gehen wir der Frage auf den Grund.

Wie nicht anders zu erwarten haben sich eine Menge Leute mit der technischen Umsetzung unserer neuen Website beschäftigt und sich sogar die Mühe gemacht sie durch den W3C Validator zu jagen. Bei vielen resultierte das jedoch in einer beeindruckend langen Liste roter Fehler. Löblicherweise hat man das nicht nur einfach stillschweigend hingenommen. Pflichtbewusst wurden wir darauf hingewiesen.

HTML5 Validation - you're doing it wrong!

An sich sollte man so reges Interesse an der eigenen Arbeit als Kompliment hinnehmen, mir stellt sich dann aber doch die Frage nach dem Warum. Wieso interessieren sich so viel Menschen dafür, ob unsere Seite validiert? Weil der Validator als Richtwert für "saubere Arbeit" gilt oder weil man einfach gerne Fehler sucht - bei anderen.

Also sehen wir uns mal die anderen Möglichkeiten an. Die Informationsseite "Why validate?" des W3 Consortiums listet folgende Gründe auf, warum man sicherstellen sollte, dass die eigene Seite standardkonform ist:

Details kann man auf der Seite des W3C nachlesen, also sehen wir uns gleich die Auswirkungen auf uns an.

Die Punkte 1 - 3 richten sich primär an die Entwickler der Seite. Sie sind dafür verantwortlich, dass die Website jetzt und in Zukunft ihren Zweck erfüllt, schnell und fehlerfrei läuft. Und das möglichst ohne regelmäßig Mehrkosten zu verursachen. Das einhalten von Standards hilft dabei definitiv, ist aber nur ein kleiner Teil der Qualitätssicherung. Denn eine Seite kann zwar validieren, jedoch trotzdem so mies konstruiert worden sein, dass die nächste Modifikation zum Fiasko wird. Ausserdem wirkt sich der Umstand nur auf die kleine Gruppe Menschen, die finanzielle Berührungspunkte mit dem Entwicklungsprozess haben, aus. Das bedeutet Kunden bei Kundenprojekten, wo wir natürlich den jeweils geforderten Standard einhalten. Und bei unserer eigenen Website wären das wir selbst ... und natürlich unsere Aktionäre! Wir werden das beim Börsengang nächstes Jahr berücksichtigen.

Viel interessanter wird es bei den Punkten 4 und 5. Hier liegt der Hund begraben, warum sich andere Leute für Markupvalidierung interessieren. Rückt man den eigenen Entwicklerkopf aber wieder in Richtung reale Welt, findet man recht schnell heraus, dass die Auswirkung gleich Null ist. Zahlt es sich also aus, die eigene Seite auf biegen und brechen standardkonform zu entwickeln? Bedingt. Waren wir zu stolz um drauf zu pfeifen? Absolut.

Entgegen vielleicht so mancher Annahme validiert unsere Seite durchaus und zwar gegen HTML5 + SVG 1.1 + MathML 3.0 + RDFa Lite 1.1 + Microdata (abgesehen von einem Warning wegen des X-UA-Compatible Headers - danke IE). Die meisten Fehlerberichte, die bei uns einlangten hatten den Validator auf XHTML 4.01 Strict konfiguriert und die Meldungen bezogen sich vor allem auf unerlaubte Tags wie "header", "article" oder "footer". Dabei handelt es sich aber nicht um die berüchtigte Tag Soup, sondern um die falsche Spezifikation.

HTML5 Validation - you're doing it right!

Interessanter Weise kümmert sich niemand um CSS Validität. Dabei ist unser Stylesheet so vollgestopft mit Vendor Prefixes, dass Jigsaw noch seinen Enkeln davon erzählen wird. Stimmt ja, CSS Validität einzuhalten ist in der aktuellen Browserlandschaft nicht praktikabel. Ich rieche Doppelmoral!

Abschließend bleibt zu sagen, dass Standards eine gute Sache sind, man sollte allerdings wissen, warum man sie einhält. Ein funktionierendes Produkt ist immer wichtiger als ein technisch lupenreines. Noch dazu wenn das Maß momentan schneller wechselt als mancher Leute Unterwäsche. Alles andere behindert Kreativität und Fortschritt.

Wird nicht veröffentlicht