molily Navigation

Pro & Contra Validität – Chronik einer laufenden Debatte

Die Webstandards-Bewegung hat vor vielen Jahren erkämpft, dass standardkonformer HTML- und CSS-Code zum qualitativen Webdesign dazugehört. Schon damals gab es Grabenkämpfe über den Sinn und Zweck des W3C-Validators: Muss eine Site immer validieren? Wie wichtig ist dieses Ziel? Was sind die praktischen Probleme von nicht standardkonformem Code? Wann muss solcher in Kauf genommen werden? Welche Fehler sind harmlos, welche bereiten Probleme?

Die Meinungen darüber gehen immer noch auseinander. Ich möchte die jüngste Debatte anhand vier Äußerungen zusammenfassen und kommentieren.

Sylvia Egger: Barrierefreiheit und Ursachen von Fehlern

Sylvia Egger konstatierte Anfang 2010: Der Quellcode gehört nur zur Aufgabe, nicht zur Lösung. Der Anlass: Die Website von Manufactum, welche mit dem Barrierefreiheits-Preis BIENE in Gold prämiert wurde, validiert nicht vollständig. Nichts, was Oliver Heeger von einer mit der Goldmedaille ausgezeichneten Site erwarten würde.

Egger wendet gegen diese Kritik ein, dass der Quellcode seine Aufgabe erfüllt und die Fehler die Robustheit nicht beeinträchtigen. Als deren Ursache macht sie die Dynamisierung der komplexen Site durch Template-Systeme sowie die Einbindung von Fremdcode verantwortlich. Im Vergleich dazu sind es laut Egger erstaunlich wenige und verschmerzbare Fehler: »angesichts dessen, was an Dynamik hinter Manufactum steht, sind die Validitätsfehler und -warnungen … minimal.« Gleichzeitig schätzt die Autorin es als möglich ein, die meisten Fehler zu schnell beheben – denn auch das bringen Template-Systeme durch ihre Modularisierung mit sich. Sie seien gleichzeitig »Fluch und Segen« für Barrierefreiheit.

Als Ergänzung hatte ich kommentiert, dass die fraglichen vom W3C-Validator aufgezeigten Fehler praktisch irrelevant sind. Vielmehr kann der W3C-Validator bei einer Validerung gegen HTML 4 prinzipiell keine Auskunft über tatsächliche Fehler geben. Der Grund dafür ist die Funktionsweise der Validierung gegen eine SGML-DTD, während kein Browser nach SGML-Regeln arbeitet. Praxisrelevanter wäre, so mein Vorschlag, eine Validierung gegen HTML5. Die Syntax und die Grammatik von HTML5 sind den tatsächlichen Verarbeitungsregeln der Browser nachgebildet. Mein Fazit lautete: HTML-4-Validatoren auf Basis von SGML sind unbrauchbar für die heutigen Anforderungen. Aussagekräftige Validierung wäre erst mit HTML5 möglich.

Dirk Jesse: Neue und nützliche Techniken kommen vor Validität

Im Juli 2010 proklamierte Dirk Jesse, Autor des CSS-Frameworks YAML: Validität ist kein Qualitätsmerkmal! In seinem Artikel stellt er grundsätzlich die Lehrmeinung infrage, dass Validität eine oberste Pflicht sei. Er kritisiert diejenigen Fachautoren, die HTML- und CSS-Anfängern die ständige Benutzung des Validators nahelegen, es aber bis dato nicht geschafft haben, »den ahnungslosen Neulingen … zu vermitteln, was Validität eigentlich bedeutet und was die Ausgaben der Validierungsdienste … bedeuten.« Besonders Unerfahrene interpretierten die Fehlermeldungen und Warnungen falsch.

Konkret nennt Jesse zwei Beispiele: Zum einen die Nutzung von CSS-3-Eigenschaften, speziell jenen mit Hersteller-Präfixen. Um beispielsweise abgerundete Ecken mit CSS 3 browserübergreifend umzusetzen, sind nicht nur zukünftige CSS-3-Eigenschaften nötig, sondern zudem eine Hand voll browserspezifischer Eigenschaften, die mit -webkit, -moz, -o und -ms, den sogenannten vendor prefixes beginnen. Der W3C-CSS-Validator erkennt diese nicht, sondern wendet standardmäßig die Regeln aus CSS 2.1 an und moniert CSS-3-Eigenschaften sowie solche mit Herstellerpräfixen mit einer Fehlermeldung. Dies ist ein falscher Alarm: Die Nutzung der experimentellen CSS-3-Implementierungen ist mittlerweile verbreitete Praxis und zeitigt keine Nachteile. Im Gegenteil, sie ist ein hervorragendes Beispiel für Progressive Enhancement.

Zum anderen nennt Jesse WAI-ARIA-Markup. ARIA ist ein Zusatz zu HTML, mit dem einen Haufen neuer Universalattributen definiert, welche die Barrierefreiheit insbesondere von clientseitig-dynamischen Webanwendungen verbessern können. Verwendet man diese Attribute in einem Dokument, welches mit einer herkömmlichen HTML-4- oder XHTML-1-Dokumenttypangabe versehen wird, so validiert das Dokument nicht. Auch diese Fehlermeldung ist verwirrend: WAI-ARIA wird vom W3C standardisiert und wird bereits breit unerstützt, einzig und allein enthält der (X)HTML-Wortschatz aus dem Jahr 1999 nicht diese Attribute. ARIA-Auszeichnungen können sehr nützlich sein und der Verzicht zugunsten von HTML-4-Validität würde die Barrierefreiheit der Site verschlechtern.

Jesse plädiert für den Einsatz dieser nützlichen Techniken. Seiner Meinung nach besteht die Gefahr, dass die W3C-Validatoren mit unangebrachten Fehlermeldungen die Webentwickler davon abhalten könnten. Des weiteren bekämen technisch nicht versierte Entscheider, die der Validator-Aussage Aussagekraft beimessen, den Eindruck, die Webentwickler hätten fehlerhaft gearbeitet. Jesse will darauf hinaus, dass »Fehlermeldungen des W3C-Validators kein hinreichendes Kriterium zur Qualitätsbewertung [einer] umsetzenden Agentur oder gar ein Anwendungsverbot für neue Standards bedeuten«. Validierung taugt seiner Meinung »zur Selbstkontrolle, zur Vermeidung und dem Auffinden von Flüchtigkeitsfehlern«. Der Validator ist ein Entwicklerwerkzeug, dessen Ausgabe einer fachkundigen Interpretation bedarf, um zu beurteilen, ob es sich bei den angekreideten Fehlern auch tatsächlich um solche handelt.

Diskussion: Validatoren nur für Wenige?

In den Kommentaren des Blogeintrages wurde heiß diskutiert. Diese Aussagen wurden noch verschärft, es wurde ihnen aber auch heftig widersprochen. Ingo Chao, ebenfalls CSS-Buchautor, wendet ein, Standardkonformität sei für ihn ein Qualitätsmerkmal unter vielen, auch wenn Validität alleine kein Garant für eine qualitativ hochwertige Site sei. Hingegen stellt Jens Grochtdreis heraus, dass die Bedienung von Validatoren und die korrekte Interpretation der Validierungsberichte derzeit nur wenigen möglich ist. Daher urteilt er: »Im Prinzip ist es ein Unding, daß die Existenz von Validatoren allgemein bekannt ist … [sie] gehören nur in die Hand von Entwicklern, die sie interpretieren können.« Außerdem könne der Validator nie die Sinnhaftigkeit, die Semantik des Codes prüfen, welche viel entscheidender sind.

In meinen Kommentaren hielt ich die Fahne der Qualitätssicherung hoch: Es ist unbedingt wünschenswert, dass den Webentwicklern Prüfprogramme zur Verfügung stehen, die aussagekräftige und harte Urteile fällen können. Es muss angemessene Regelkataloge geben, gegen die automatisiert geprüft werden kann. Das Problem ist lediglich, dass die W3C-Validatoren veraltet sind. Dies ist aber bloß ein technisches Problem, was in absehbarer Zeit lösbar ist: Es ist schon jetzt möglich, valides HTML mit WAI-ARIA zu schreiben. HTML5 hat ARIA bereits eingebaut, zudem gibt es Dokumentyp-Definitionen (DTDs) für HTML 4 und XHTML 1.1 erweitert um ARIA-Attribute. Und seitens des CSS-Validators wird gerade diskutiert, ob Herstellerpräfixes nicht akzeptiert werden und lediglich Warnungen auslösen. Es ist richtig, dass Validierung ein gewisses Grundwissen verlangt. Aber auch an dieser Front wird gearbeitet: Unter anderem Validatoren wie Validome.org (derzeit offline) haben versucht, die Fehlermeldungen mit verständlichen Erklärungen aufzubereiten. Dies müsste fortgeführt werden. Alles in allem erachte ich Validatoren durchaus auch für Einsteiger als geeignet.

Remy Sharp: Does validation matter?

Kürzlich hat Remy Sharp die Diskussion aufleben lassen mit einer Website, die aus guten Gründen nicht valide ist: doesvalidationmatter.com. Die Antwort lautete anfangs schlicht »No«. Nach einiger Kritik schwächte er dieses plakative Statement ab und plant nun einen differenzierten Text. Im Quellcode ist bereits zu lesen: »validation is a good learning tool, something that you can benchmark your markup against and hold your code up to.« Wichtiger als valider Code sei jedoch: »it's important to understand the code you've written and how it works.« Wenn das Markup nach allgemeiner Auffassung in Ordnung ist, sollten Validierungsfehler nicht verhindern, dass eine Site veröffentlicht wird.

Auf Remy Sharps Provokation ließen Chris Heilmann und Nicholas C. Zakas längere Artikel folgen.

Chris Heilmann: Validierung bleibt der erste Schritt

Chris Heilmann kritisiert, dass eine pauschale Aussage wie »Validation doesn't matter« von Autoritäten wie Sharp missverstanden und als Entschuldigung für Steinzeit-Code missbraucht werden könne. Er hält dagegen, wie gefährlich fehlerhaftes HTML sein kann: »If I write invalid HTML the browser either ignores it or – what is actually worse – tries to fix it for me.« Heilmann gesteht ein, dass durch verschiedene Entwicklungen das Streben nach validem Markup obsolet geworden ist: Abgesehen davon, dass die W3C-Validatoren veraltet und zu streng sind, leben moderne Webanwendungen von der kreativen Markup-Zweckentfremdung und die Praxis erfordert fragwürdige Lösungen.

Nichtsdestoweniger bricht Heilmann eine Lanze für die Validierung: Sie ist seiner Meinung nach immer der erste Schritt, um die grundlegendsten Fehler aufzuspüren. Er verteidigt daher, das Helfende in Chats und Support-Foren erst einmal zur Validierung raten. Probleme sieht er jedoch ebenfalls in der möglichen Fehlinterpretation der Ergebnisse und dem Auseinanderklaffen zwischen Browser-Realität und Validatorregeln. Das Verbot, auf keinen Fall invaliden Code schreiben zu dürfen, hemmt unter anderem die Weiterentwicklung der Barrierefreiheit. Dabei sind gerade im Bereich der Barrierefreiheit automatisierte Tests wenig aussagekräftig.

Heilmann schlägt in eine ähnliche Kerbe wie die vorangenannten: Validerung liefere einen wichtigen Beitrag zur Qualitätssicherung, sie stehe jedoch am Anfang und nicht am Ende des Prozesses. Er plädiert dafür, die Webentwickler darin zu schulen, Validerungsausgaben verstehen und bewerten zu können. Gleichzeitig müssten die Validatoren weiterentwickelt werden, um den Webentwickler darin entgegen zu kommen.

Nicholas Zakas: HTML 4 ist zu streng, HTML5 ist näher an der Realität

Nicholas Zakas’ Antwort fragt nach dem Nutzen der Validierung und zielt in die entgegengesetzte Richtung. Er verortet sich in der Contra-Ecke und stellt die Probleme heraus, die HTML-Validierung unbrauchbar machen, und zeigt mögliche Lösungen auf. Insgesamt spricht er validem HTML jede Aussagekraft hinsichtlich Zugänglichkeit, Browserkompatibilität und Benutzerfreundlichkeit ab. Das alles kann valides HTML alleine nicht garantieren.

Zunächst erklärt Zakas, welche Prüfungen der Validator vornimmt, und welche ihn davon zu streng sind. Er findet es uneingeschränkt nützlich, dass der Validator allgemeine Syntax- und Verschachtelungsfehler ankreidet. Ebenso, dass beim Standard-HTML die Grammatik überrüft wird, wie sie in der DTD notiert ist. Ein Problem hat Zakas jedoch damit, dass der Validator unbekannte Elemente und Attribute ablehnt. In diesen Bereich fallen HTML-Erweiterungen wie WAI-ARIA (siehe oben). Eigene Attribute seien nützlich, um beispielsweise für das Scripting Zusatzdaten im Dokument unterzubringen.

Unbekannte Elemente und Attribute werden – solange sie syntaktisch korrekt sind – von neueren Browsern nämlich ohne Murren eingelesen und ins DOM übernommen. Praktische Probleme bereiten sie daher nicht. Der Validator sollte nach Zakas Meinung lediglich mit Warnungen auf sie reagieren, damit der Webentwickler prüfen kann, ob er nicht vielleicht ein HTML-eigenes Attribut falsch geschrieben hat. Aus dieser Situation wird HTML5 etwas den Druck nehmen: HTML5 unterstützt ARIA wie gesagt von Haus aus und erlaubt eigene Attribute mithilfe des data-Präfixes. Die Nutzung von HTML5 und dem HTML5-Validator sieht Zakas daher als kurzfristige Abhilfe an, sie löst die schwerwiegenden Probleme, die er mit Validierung hat: »[the HTML5 validator] more accurately reflects real-world use cases than the HTML 4 validator.«

Browser haben nur einen HTML-Parser

Ferner spricht Zakas einen wichtigen Sachverhalt an, der gar nicht oft genug wiederholt werden kann: Die Angabe des bestimmten Dokumenttyps wie z.B. XHTML 1.0 Strict ist bei der Entwicklung entscheidend – bei der Darstellung im Browser allerdings wenig relevant. Der HTML-Parser im Browser verarbeitet alle (X)HTML-Dokumente mit dem MIME-Typ text/html gleich. Auch Peter Kröner weist in einem Blogeintrag darauf hin, dass dem Browser Art und Inhalt eines DOCTYPEs komplett egal sind.

Die Dokumenttyp-Angabe, kurz DOCTYPE, beeinflusst lediglich die CSS-Verarbeitung, siehe DOCTYPE-Switch. Wer eine standardgetreue CSS-Verarbeitung wünscht, der sollte einen DOCTYPE wählen, der den standardkonformen Rendermodus anschaltet. Neben diesem besitzen die Browser mindestens noch den Quirks-Modus, in dem der Browser aus Gründen der Abwärtskompatibilität vom CSS-Standard abweicht.

Unabhängig vom DOCTYPE läuft das Parsing des HTML-Codes jedoch immer gleich ab. Der Browser kennt immer dieselben Elemente und Attribute. Er akzeptiert z.B. das font-Element auch in HTML 4.01 Strict, wo es eigentlich nicht erlaubt ist. Er toleriert XHTML-Schreibweisen wie <meta /> auch in HTML 4, wo sie eigentlich eine andere Bedeutung haben. Umgekehrt werden neue HTML5-Elemente auch in HTML-4-Dokumenten erkannt. Der Browser wendet immer dieselben Regeln an, wenn er auf Fehler trifft. Als Reaktion darauf definiert HTML5 einen Parser, der mit sämtlichen HTML-Dokumenten im Web umgehen kann, egal welcher DOCTYPE angegeben wurde.