Dienstag,
27. Juli 2010

Dieser Beitrag zu Validität und ihrer Bedeutung in der aktuellen Webentwicklung liegt mir schon seit Monaten auf der Zunge. Bisher gab es immer genug Ablenkungen, ihn nicht zu schreiben. Heute ist das anders, denn heute hat mich eine Anfrage im YAML-Forum dazu gebracht, dieses Thema endlich mal wieder auf den Tisch zu bringen.

Worum geht es? Vor langer Zeit als die Welt noch schwarz-weiß ... als das Web noch jung und HTML4 Quellcode noch fürchterlich chaotisch und gefühlt frei jeglicher Stilregeln geschrieben werden konnte, da kamen einige schlaue Webschaffende auf die Idee, dass es doch ein wirklicher Fortschritt wäre, wenn sich die Entwicklergemeinde an Standards halten würde. Webstandards kamen in Mode und der Ruf nach sauberem, validem Code drang selbst in die hintersten Gassen. XHTML 1.0 war damals der große argumentative Renner, denn XHTML zwang Webentwickler zu Ordnung und Sauberkeit im Code. Tags mussten geschlossen, Attributwerte zwingend in Anführungszeichen gesetzt werden. Die jahrelange Arbeit mit XHTML hat mir zwar XML an sich kein noch so kleines Stückchen sympathischer gemacht (aufgrund seiner Fehlerintoleranz) aber es hat mich gelehrt sauberen Code zu schreiben.

Und da auch ich zu denen gehöre die Bücher veröffentlichen, um mein Wissen um HTML & CSS weiterzugeben, bin ich auch nicht ganz unschuldig an der Situation, die sich uns Entwicklern heute bietet. Seit vielen Jahren predigen wir: Validiert Euren Code! Wenn irgendetwas nicht funktioniert und Ihr jemanden nach Hilfe fragen wollt: Erst validieren – dann jemanden fragen! So oder so ähnlich liest man es in jedem CSS-Buch (und davon gibt es mittlerweile reichlich). Leider haben offensichtlich die wenigstens Autoren es bisher geschafft, den ahnungslosen Neulingen in einfachen Worten zu vermitteln, was Validität eigentlich bedeutet und was die Ausgaben der Validierungsdienste des W3C (HTML | CSS) wirklich bedeuten.

Dieser Umstand ist mir so richtig klar geworden, als ich vorhin über folgendes Foreneintrag gestolpert bin:

Hallo Zusammen!

Ich habe per CSS folgende Codes eingefügt um einen Text vertikal darzustellen. Soweit funktioniert das auch. Jedoch bei der W3C Validierung werden diese CSS Anweisungen als Fehler deklariert. Gibt es hierzu auch eine valide Möglichkeit?

Dazu wurde folgender Codeschnipsel mitgeliefert:

-webkit-transform: rotate(-90deg); 
-moz-transform: rotate(-90deg);    
-o-transform: rotate(270deg);

Ein Einsteiger präsentiert sauberes CSS3, denkt bei den Vendor-Präfixes an alle wichtigen Browser, freut sich zurecht über den Erfolg (”...Soweit funktioniert das auch…”) und wendet sich anschließend trotzdem verzweifelt an ein Forum weil der W3C-Validator ihm ein schlechtes Gewissen eingeredet hat. Das muss definitiv aufhören, denn spätestens wird das ehemalige Mantra der Pflicht-Valität zum Boomerang für uns erfahrenere Entwickler, denn hier werden die Aussagen des Validators fehlinterpretiert.

Wie funktioniert ein Validator?

Der Validator prüft also die Gramatik des Codes, also die richtige Verwendung von Klammern, Anführungszeichen, Elementverschachtelungen etc. Für die Rechtschreibprüfung verwendet der Validator ein Wörterbuch. Bei HTML werden also Tags und Attribute, bei CSS Eigenschaften und Werte anhand einer Wortliste überprüft. Werden sie gefunden, ist alles in Ordnung. Hat sich jedoch ein Tippfehler eingeschlichen, dann wird das entsprechende Schlüsselwort in der Liste nicht gefunden und der Validator gibt einen Fehler aus. Unbekannte Elemente werden somit ebenfalls als Fehler behandelt. Bei der Validierung von HTML war dieses Vorgehen des Validators in der Vergangenheit auch in Ordnung, denn das jeweils verwendete HTML-Wörterbuch wählt der Validator anhand des in der Webseite vorgegebenen DOCTYPES aus. Elemente, die in der jeweiligen Spezifikation nicht enthalten sind, erzeugen somit Fehlermeldungen.

Das Problem

Ganz so einfach ist es halt doch nicht, denn neben HTML existieren mittlerweile zahlreiche Standards, die den HTML-Standard erweitern. Als Beispiel sei hierfür WAI-ARIA genannt, womit HTML durch zusätzlich Attribute mit semantischen Informationen angereichert wird. ARIA wird von allen relevanten Browsern (einschließlich IE6) und den aktuellen Screenreadern unterstützt. Screenreadernutzer profitieren daher schon länger von diesen Zusatzinformationen. Der W3C Validator kennt diesen Standard hingegen noch nicht – vermutlich weil er noch immer nicht aus dem Draft-Status heraus gekommen ist. Die Konsequenz daraus für den unwissenden User: Die durchaus sinnvollen ergänzenden ARIA-Attribute werden dem User als Fehler ausgewiesen.

Folgenden Satz bekam ich bei der Einführung von WAI-ARIA in den YAML-Beispielen vor knapp einem Jahr regelmäßig in e-Mails zu lesen:

Wir bekommen auf jeder Seite folgenden Fehler:
——————————————————————————————
Line 35, Column 31: there is no attribute “role”
      <div id=“header” role=“banner”>

Gut gemeint und doch spukt der Validator eine Fehlermeldung aus, ohne jede zuätzliche Erklärung. Leider hat der W3C-Validator hier noch eine schwache Ausrede, denn formal gehört sich in diesem Fall auch ein passender DOCTYPE, der XHTML + WAI-ARIA ankündigt. Leider gibt’s den aber meines Wissens auch noch nicht wirklich. Der Akzeptanz von WAI-ARIA ist damit nicht gerade ein roter Teppich ausgerollt, obgleich ich jedem ernsthaften Entwickler nur ans Herz legen kann, sich damit zu beschäftigen.

Noch nerviger ist die Situation bei Cascading Stylesheets. Auch hier hat sich die Entwicklergemeinde in den letzten Jahren aus der IE6-Lethargie gelöst und propagiert aus guten Gründen Progessive Enhancement Strategien. Dank der rapide wachsenden CSS3-Unterstützung durch Firefox, Chrome und Opera trifft dieser Ruf auch auf immer mehr willige Entwickler – wie den vornweg zitierten Kollegen. Nur leider steht das erste “C” für “Cascading” also ein aufeinander aufbauendes System. Jeder neue CSS-Standard erweitert den bestehenden Sprachschatz. Zu dumm, dass das W3C den CSS3-Standard zwar kennt, jedoch in den Standardeinstellungen Stylesheets hart nach CSS 2.1 validiert und der Validator die “unbekannten” CSS3-Eigenschaften ebenso als Fehler behandelt, wie jeden wirklichen Tippfehler.

Und um Neueinsteiger restlos zu verwirren, erkennt der W3C Validator die überwiegende Zahl der heute bereits verwendeten CSS3-Regeln noch nicht einmal dann als korrekt, wenn man seine Stylesheets gegen CSS3 validiert. Denn beim W3C kennt man offensichtlich keine Vendor-Präfixes, die das W3C den Browserherstellern selbst vorschreibt, solange neue CSS-Eigenschaften lediglich experimentell implementiert sind. Und damit fliegen uns die meisten runden Ecken, Box- und Text-Schatten oder Gradienten reihenweise um die Ohren.

Als Beispiel hier ein Test, mit der CSS3-Eigenschaft -moz-border-radius (Das Vendor-Präfix “-moz” steht für Mozilla) den folgenden fehlerfreien Code gegen CSS3 validieren zu lassen:

body { -moz-border-radius: 5px; }

Dazu meint der freundliche CSS-Validierungsdienst des W3C ...

Mir ist klar, dass eine solche Meldung für Einsteiger nicht nur respekteinflößend ist, sondern gelegentlich (bei aktuell noch weniger bekannten CSS3-Eigenschaften) regelrecht verschreckt. Nicht umsonst fragte oben zitierter Neuling, ob es denn auch eine valide Lösung für sein real nicht vorhandenes Problem gäbe.

Aufklärung dringend notwenig

Was die Webstandards-Gemeinde angefangen hat, muss sie jetzt auch weiter durchziehen. Einsteiger und unwissende Entscheider müssen darüber aufgeklärt werden, dass Fehlermeldungen des W3C-Validators kein hinreichendes Kriterium zur Qualitätsbewertung der umsetzenden Agentur oder gar ein Anwendungsverbot für neue Standards bedeuten. Es muss klar werden, das – wie bei jeder automatischen Rechtschreibprüfung – aktuell kein Validator in der Bewertung einen Unterschied zwischen einem echten Rechtschreibfehler und einen ihm unbekannten Schlüsselwort macht. Vergleichbares kennt man von Rechtschreibprüfungen in Textverarbeitungen. Kaum ein Programm ist in der Lage, Substantive und Verben auch in all Ihren Beugungsformen und Fällen zu erkennen. Gleiches gilt für die Erkennung von Namen.

Ich weiß, dass viele gestandene Entwickler hier kommentieren werden, dass sie sich um die Ergebnisse des W3C-Validators nicht (mehr) scheren. Doch das allein hilft weder Einsteigern noch Entscheidern, sich zurechtzufinden. Beide Zielgruppen nehmen den W3C Validator (oder auch Hilfsmittel wie das HTML Validator-Plugin für den Firefox) offensichtlich als stichhaltiges Werkzeug zur Qualitätsbeurteilung war. Für Webentwickler und aus der Sicht eines Buchautors halte ich diese Entwicklung für falsch. Deshalb hilft nur eines: Weiter und besser darüber aufzuklären, was Validität bedeutet.

Meine Definition

Validität ist kein Qualitätsmerkmal! Eine Validitätsprüfung ist eine automatische Gramatik- und Rechtschreibprüfung für HTML- und CSS-Code auf Basis eines definierten Wortschatzes.

Eine Validitätsprüfung sagt daher genauso wenig über die Codequalität wie die automatische Rechtschreibprüfung von Microsoft Word oder Open Office mit dem vorinstallierten Standardwörterbuch über meine Fähigkeiten, gute und fehlerfreie Fachtexte zu schreiben. Die Prüfung ist wichtig zur Selbstkontrolle, zur Vermeidung und dem Auffinden von Flüchtigkeitsfehlern und somit ein Entwicklerwerkzeug.

Ich hoffe, diese Analogie hilft etwas, das Verständis der Materie zu verbessern. Vermutlich habe ich mal wieder viel zu viel geschrieben, dennoch: es musste mal gesagt werden.Den unsicheren User im Forum werde ich jetzt etwas aufmuntern ...


Du kannst die Kommentare zu diesen Eintrag durch den RSS 2.0 Feed verfolgen. Du kannst einen Kommentar schreiben, oder einen Trackback auf deiner Seite einrichten.

Dieser Eintrag kann nicht mehr kommentiert werden.