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 ...
Mittwoch, 28.07.10 (00:09 Uhr)
Sehr guter Artikel!
Im Grunde genommen hast du Recht, trotzdem ist valider Code in gewisser Weise wichtig. Mit
hast du sehr gut ausgedrückt, wieso es wichtig ist seinen Code zu validieren bzw. sich Gedanken darüber zu machen.
Über jeden Fehler den man findet sollte man zumindest nachdenken. Jemand, der z.B. WAI-ARIA einsetzt wird die entsprechenden Validierungsfehler zurecht ignorieren.
Wenn ich aber gerade dabei bin (x)HTML zu lernen, kann mir der Validator viel Feedback geben und eventuelle Fehler aufzeigen, die ich gemacht habe.
Ob ich mich im Endeffekt daran halte oder nicht bleibt mir ja trotzdem selber überlassen.
Wichtig ist meiner Meinung nach jedoch, dass man sich Gedanken darüber gemacht hat und sich mit diesem Thema auseinander setzt.
Mittwoch, 28.07.10 (00:18 Uhr)
@Traxmaxx Volle Zustimmung. Den abschließenden Satz hatte ich völlig vergessen. Validierung ist eine wichtige Selbstkontrolle und ein hervorragendes Werkzeug zum Auffinden von Flüchtigkeitsfehlern. Durch beides fördert sie sauberen Code.
Mittwoch, 28.07.10 (09:16 Uhr)
Ich sehe das genau so wie du im letzten Absatz schreibst.
Mittwoch, 28.07.10 (09:20 Uhr)
Auch die “Rechtschreibung” und “Grammatik” ist Teil der Standard compliance und damit sicherlich ein Qualitätsmerkmal. Aber naja. Deine Kritik an den Buchautoren macht betroffen. Immerhin: Validierung sei unerlässlich, schreiben wir. Und auch: Mit nicht validem XHTML und CSS testet man lediglich die Fähigkeit der Browser, sich von Fehlern im Markup und Stylesheet wieder erholen zu können und dabei trotzdem in etwa das anzuzeigen, was mutmaßlich im Sinne des Autors war.
Mittwoch, 28.07.10 (12:54 Uhr)
@Ingo
Ich stelle weder “Rechtschreibung” noch “Gramatik” in Frage. Was mich stört, ist das insbesondere Einsteiger/Laien dieser automatischen Kontrollinstanz derart vertrauen, dass Sie sie als hartes Qualitätskriterium warnehmen, wie die Beispiele nach meinen Erfahrungen belegen.
Ein Dokument ist eben nicht zwingend fehlerfrei, nur weil die Automatismen von Word nichts mehr zu beanstanden haben. Bei der Kommasetzung gibt’s keine automatischen Hilfen. Und für das Wörterbuch unbekannte Wörter versprühen für Fremdsprachler in einem deutschen Text ebenso leicht wie unberechtigt den Verdacht des Fehlerhaften.
Vergleichbares beobachte ich im Web. Mit HTML 4/XHTML 1.0 und CSS2 kamen und kommen die Validatoren sehr gut klar. Bei Anwendung neuer Standards (CSS3, ARIA, HTML5) habe ich persönlich keine Schwierigkeiten mit der Validierung, denn ich weiß, wie ich die Fehlermeldungen zu deuten habe. Aber gerade bei Gelegenheitsanwendern, Einsteigern und Entscheidern (die die Validierung als Qualitätskontrolle einsetzen) bemerke ich in letzter Zeit vermehrt Verwirrung. Die Entwicklung der neuen Standards geht aus unserer Sicht vielleicht langsam voran, für Außenstehende ergibt sich aber vielleicht ein etwas anderes Bild.
Deshalb ist meine Empfehlung, die richtige und wichtige Validitätsprüfung auch in unseren Veröffentlichungen weniger als Prüfsiegel sondern vielmehr—wie auch geschrieben—zur Selbstkontrolle zu verstehen. Betroffenheit kommt bei mir nicht auf. Ich verstehe es eher als positives Zeichen, dass die Rufe der Webstandardsszene weniger ungehört verhallen als man es im Alltag vielleicht vermutet.
Mittwoch, 28.07.10 (13:40 Uhr)
Du stellst Validität als Qualitätsmerkmal infrage. Für mich ist es eins. Wir haben eine andere Sichtweise auf den Begriff der Qualität. Validität bedeutet sicherlich nicht, da sind wir uns einig, dass eine Seite an sich qualitativ hochwertig ist. Das überrascht nicht.
Ich spreche mich explizit gegen eine Validerung als Selbstzweck, gegen eine Validierung zum Anheften des Buttons für den Kunden aus. Ich kann daher nicht ganz sehen, worauf deine Kritik an den Publikationen fußt. Auf dem Allgemeinplatz in Klammern, es gebe zu viele Bücher?
Mittwoch, 28.07.10 (13:53 Uhr)
Jeder sollte seine Webseiten validieren, aber mit Verstand und dem Wissen, dass dies eben nichts über die Qualität, sondern nur über die eingestellte (!) Konformität etwas aussagt.
Mittwoch, 28.07.10 (14:04 Uhr)
Wenn Konformität für dich kein Qualitätsmerkmal ist, definierst du dann Qualität nicht auf einem sehr hohen, sehr abstrakten, aber leider nicht mehr messbaren Level? Wenn Qualität dann nicht mehr beschreibbar ist, man also keinen Vergleich mehr anstellen kann, ist der Begriff der Qualität nutzlos, weil ziellos.
Ich mache es mir da einfacher: Standardskonformität ist ein Qualitätsmerkmal unter vielen.
Mittwoch, 28.07.10 (14:05 Uhr)
Wie gerufen kommt da natürlich der heutige drweb.de-Artikel, dem ebenfalls die gleiche, verquere Vorstellung von Validität zu Grunde liegt. In diesem Fall wird sogar Accessibility nur zugunsten von Validität geopfert.
drweb.de/magazin/trotz-facebook-widgets-eine-valide-seite/
Mittwoch, 28.07.10 (17:12 Uhr)
»Validität ist kein Qualitätsmerkmal!«
Wie du in der Diskussion präzisierst, meinst du das gar nicht so.
Zum Thema wäre anzumerken: Validierung, die ein hartes, brauchbares Urteil abgibt (valide gemäß Anforderungen oder nicht valide), ist nützlich und wichtig. Es ist auch weiterhin wünschenswert, dass es allgemein akzeptierte Anforderungskataloge gibt, deren Konformität sich maschinell überprüfen lässt. Wir Webdeveloper sollten solche Regeln formulieren.
Wenn Validierung hingegen vor allem False Negatives produziert, dann benutzt man falsche oder fehlerhafte Tools, die unbrauchbare Kriterien anlegen. Klar, dann verliert Validierung ihre Nützlichkeit zur (automatisierbaren) Qualitätskontrolle und ihre Aussagen sind Makulatur, wenn man Fehlermeldungen (nicht Warnungen) noch einmal gegenchecken muss.
An den Validierungstools muss daher gearbeitet werden, das stellst du richtig fest. Deshalb ist aber die Idee von HTML-/CSS-Validierung und dessen Stellenwert beim Webauthoring jedoch nicht nachhaltig geschmälert.
Der CSS-Validator hat einfach Versäumnisse, er sollte Vendor-Prefixes erkennen. ARIA hingegen ist m.W. mittlerweile kein Grund mehr für nicht-valides Markup. Es gibt eingebautes ARIA in HTML5, daher kann man schlicht den HTML5-Doctype verwenden. Außerdem liefert der ARIA-Standard vorgefertigte DTDs für XHTML 1.1 + ARIA und HTML 4.01 Transitional + ARIA.
http://www.w3.org/TR/wai-aria/appendices#xhtml_dtd
http://www.w3.org/TR/wai-aria/appendices#html_dtd
Mittwoch, 28.07.10 (17:43 Uhr)
Der Artikel spricht mir aus er Seele. Vielen Dank für die Mühe, das so ausführlich darzustellen. Ist keineswegs zu lang.
Mittwoch, 28.07.10 (17:58 Uhr)
@molily
Doch, ich meine es. Natürlich sehe ich die Vorteile einer automatisiert und nach festen Kriterien prüfbaren Qualität. Aber wenn das so einfach wäre, bräuchte die Biene-Jury keine dezidierten Nutzertests fahren.
Folgende Konstruktion ist valide—und dennoch ein rotes Tuch für jeden, der Webstandards für etwas Erstrebenswertes hält:
<div class=“hauptueberschrift”><img src=“img003.gif” alt=”“></div>Weder die heutigen Ansprüche an die Semantik, noch die allgemeinen Grundlagen der Zugänglichkeit sind in diesem Beispiel erfüllt. Ich würde daher trotz fehlerfreier Validierung in diesem Zusammenhang nie das Wort Qualität gebrauchen wollen.
Zu einem echten Qualitätsmerkmal wird die Validierung nur in den Händen fachkundiger Entwickler, die sich der Tragweite ihrer Entscheidungen hinsichtlich des Quellcodes bewusst sind.
Auch wenn es in Deinen und Ingos Augen vielleicht spitzfindig erscheint, Validität ist kein Qualitätsmerkmal. Es ist ein Kriterium, über welches sich die Qualität einer Seite bewerten lässt - oft auch ein Notwendiges. Aber Validität allein ist eben nicht hinreichend für Qualität. Und dieser Punkt wird meiner Meinung nach zu oft falsch verstanden, denn die meisten Außenstehenden und Einsteiger können oft andere Kriterien (für die es keine Automatismen per Knopfdruck gibt) nicht beurteilen oder sind sich derer nicht einmal bewusst.
Aber ich finde es erfrischend, wie schnell die Diskussion hier nach so langer Stille wieder in Gang kommt. Danke dafür an alle, die sich beteiligen.
Mittwoch, 28.07.10 (21:57 Uhr)
Validität ist für mich sehr wohl ein Qualitätsmerkmal. Nicht-valide Code-Passagen lasse ich nur durchgehen, wenn ich das gut begründen kann. Bei Vendor-Präfixen und MSIE-“filter” kann ich das, bei manchen IE-Hacks und zoom: 1 eher weniger.
Dass Validatoren Undinger wie “font-size: blue” nicht bemängeln, sagt nichts über die Tauglichkeit von Validierung an sich aus, sondern nur etwas über die Tauglichkeit des Validators. Jeder Browser erkennt, dass er dieses Dingens nicht in die Tat umsetzen kann, warum sollte ein Validator das nicht auch erkennen können?
Da der Browser die letzte Instanz ist, kommt er nicht darum herum, den Code bis auf die blanken Knochen auf Validität zu prüfen. An dem bleibt also hängen, was vorher versäumt wurde. Jahreinjahraus werden auf den Computern von -zig Besuchern Prozessortakte für immer den gleichen, nutzlosen Unsinn verplempert. Man könnte es also einmal prüfen, korrigieren und Ruh’ wär’.
Ergo: fehlerfreier Code ist effizienter und zukunftssicherer und daher qualitativ besser. Auch wenn der praktische Gewinn durch ein gelöschtes “font-size: blue” nicht wahrnehmbar sein dürfte, besser ist es so trotzdem. Und nur darum ging es: ob validierender Code besser ist.
Donnerstag, 29.07.10 (06:35 Uhr)
Nur weil es gerade zum Thema passt. Das W3C hat seine Validierungsdienste jetzt vereinheitlicht,
auf http://validator.w3.org/unicorn/.
Donnerstag, 29.07.10 (08:18 Uhr)
Ich hatte auch gerade eine Leseranfrage, warum ich denn die CSS-Validierung im Buch empfehle und auf little-boxes.de selbst nicht mache. Und wenn ich sie mache, warum ich dann kein “Valiedierungsprüfungssymbol” (Originalschreibweise) auf den Seiten habe. Die Analogie mit der automatischen Rechtschreibprüfung hätte gut gepasst und wird in Zukunft helfen, einen Validator richtig einzusetzen. Thank you dafür.
Donnerstag, 29.07.10 (11:22 Uhr)
Dazu ist vielleicht auch mein Blog-Beitrag vom Februar 2006 ganz interessant, der eine ähnliche Meinung vertritt.
Donnerstag, 29.07.10 (14:03 Uhr)
Ich hatte vor, was ähnliches zu schreiben, sehr schön und kompakt zusammengefasst. vViele Leute verwechseln validen Code mit Barrierefreiheit.
Freitag, 30.07.10 (11:54 Uhr)
Auch ich finde, daß Validität kein Qualitätskriterium ist. Es ist nicht viel mehr, als die Rechtschreibprüfung in Word. Der Validator gibt mir Hinweise, ob ich Klammern nicht geschlossen habe, Attribute fehlen oder an den falschen Stellen sind oder daß ich “target” nicht benutzen darf. Mehr nicht. Ich kann einen prima Tabellenverhau ohne jegliche semantische Information schreiben, die Seite würde als valide durchgehen.
Im Prinzip ist es ein Unding, daß die Existenz von Validatoren allgemein bekannt ist, denn nicht jeder kann sie bedienen und korrekt lesen. Man muss sie interpretieren. Man kann darüber streiten, ob man für jedes unmaskierte “&”-Zeichen in einer URL ein Fass aufmachen muss. Ich persönlich ignoriere das.
Validität gibt mir nur eine erste Information. Ein tieferer Blick in Code zeigt mir hingegen, ob mit oder ohne Hirn gearbeitet wurde. Ob also Semantik existiert oder nicht. Schaut Euch den Code von Stern.de an und urlteil selbst ob es etwas brächte, wäre der valide. Meiner Meinung nach fehlt es da komplett an sinnvoller Semantik, die wäre wichtiger.
Und solange das W3C keine Validatoren zur Verfügung stellt, die ihre eigenen in Entwicklung bzw. Ruhezustand befindlichen Regeln korrekt überprüfen, kann man mit der Meinung eines Validators unkommentiert noch viel weniger anfangen.
Es ist leider so: Validatoren sind nicht zu mehr nutze, als zur Rechtschreibkontrolle und gehören nur in die Hand von Entwicklern, die sie interpretieren können.
Freitag, 30.07.10 (13:06 Uhr)
Sodass — wenn ich die Analogie mit der automatischen Rechtschreibprüfung auch einmal belasten darf — diese Prüfung nur von fortgeschrittenen Schreibern benutzt werden sollte, weil nur diese in der Lage wären, zu erkennen, dass damit eben keine Prüfung der Klarheit des Gedankengangs erfolgen könnte? Das versteigt sich ins Elitäre. Bin dann mal weg.
Freitag, 30.07.10 (14:56 Uhr)
@Ingo: Nein. Das siehst Du völlig falsch. Aber eine reine Rechtschreibeprüfung kann doch keinen sinnfreien, dadaistischen Satz von einem sinnhaften Satz unterscheiden. Darum geht es mir. Validatoren können über Sinnhaftigkeit, also Semantik, nichts sagen. Deshalb ist ein Validator und die formale Validität nur der erste Schritt und nicht unbedingt der Wichtigste. Es kann nicht der Wichtigste sein, weil moderne CSS3-Eigenschaften nicht valide sind. Das ist nicht sinnvoll und nur mit Nachlässigkeiten beim W3C zu begründen. Validität ergibt nur mit anderen Faktoren zusammen ein vernünftiges Bild. Allein sagt es nicht viel aus.
Freitag, 30.07.10 (20:21 Uhr)
Ich sehe das von einem technischen Standpunkt. Es sind Tools, die nach gewissen Algorithmen, Regelkatalogen und Vokabularen prüfen. Die Tools sind so gut wie diese. Auf der CSS-Validator-Mailingliste wird in letzter Zeit öfters über CSS3-Techniken mit vendor prefixes diskutiert. Viele fordern dort, dass Eigenschaften mit vendor prefixes lediglich Warnungen/Meldungen erzeugen. Vielleicht programmiert das jemand, der Java kann, einfach mal in ein paar Stunden in den CSS-Validator ein, und das Problem hat sich gegessen.
So richtig wird nicht klar, worin die Kritik an Validierung besteht. Zuerst war es ARIA, wo ich bereits angemerkt habe, dass ARIA die Validierung nicht mehr verunmöglicht. Dann werden CSS3-Eigenschaften genannt, auch das ist technisch gesehen vermutlich einfach in den W3C-CSS-Validator integrierbar. Letztlich sind es die allgemeinen Einwände, ein Validator könne nie die Semantik prüfen. Völlig richtig, man kann nicht müde werden, zu betonen, wie der Validator funktioniert, wozu er sich eignet und welche Aussagekraft Validität hat. Man sollte einerseits konkrete technische Kritik üben und die notwendige Weiterentwicklung der Tools vorantreiben. Andererseits gilt es die grundsätzliche Bedeutung und die Einsatzmöglichkeiten von Validatoren zu erörtern.
Sorry, das ist nun Quatsch und tatsächlich ein elitistisches Argument, mit dem sich auch das Verschweigen von Wissen über HTML und CSS rechtfertigen ließe.
Montag, 02.08.10 (12:13 Uhr)
Aus meiner Sicht ist es nicht verwerflich, VOR der Nutzung des W3C-Validators und der Interpretation von dessen Ergebnissen ein gewisses Grundwissen vorauszusetzen. Daran ist nichts elitär.
Der Validator liefert in der Regel keine Fehlermeldungen, die für Laien unmissverständlich sind und darüber aufklären, was welcher Fehler zu bedeuten und welche konkreten Auswirkungen sich daraus für die Benutzung der Seite ergeben. Und ich sage es gern nochmal: Die von mir hier vorgestellten Nutzerfragen sind keine Seltenheit. Sie zeigen, dass für Leute ohne Frontenderfahrung großer Raum für Missverständnisse besteht—und das ist der Ansatzpunkt meiner Kritik in diesem Beitrag.
Es gibt Werkzeuge, die sind für Laien und es gibt Werkzeuge für Fachleute. Wo ist das Problem, aus Entwicklersicht zu akzeptieren, dass man Einsteiger oder Fachfremde nicht zwingend die gleichen Tools empfielt, die man selbst nutzt. Wir haben schließlich auch nicht alle Linux installiert und schreiben unsere Briefe mit vim—obgleich es genügend eingefleischte Programmierer gibt, aus deren täglicher Arbeit sich beides nicht wegdenken ließe.
Mich würden Vorschläge interessieren, wie man Neulingen das Thema Codequalität nahe bringt, ohne Sie mit den Wirren der Validatoren in Verbindung mit aktuellen Webtechnologien zu verschrecken.
Dienstag, 03.08.10 (14:14 Uhr)
»Der Validator liefert in der Regel keine Fehlermeldungen, die für Laien unmissverständlich sind ...«
Auf die Gefahr hin, mich zu wiederholen: Das mag sein, aber das ist doch kein Naturgesetz. Das ist doch keine Eigenschaft, die jeder Validator notwendigerweise hat. Es gibt verschiedene Versuche, einen HTML-Validator z.B. an HTML-Dokumentationen anzubinden, etwa Validome. Die Regelkataloge zu verfeinern und auszubauen. Die Fehlermeldungen mit Erklärungen, Links, Übersetzungen zu versehen. Kriterien zu überprüfen, die weit über korrekte Syntax hinaus gehen. Was meint ihr, wieviel solche Arbeit in den letzten Jahren in den W3C-HTML-Validator geflossen ist. Der entstehende HTML5-Validator braucht noch sehr viel Zuwendung diesbezüglich. Dessen Meldungen verstehe nicht einmal ich. Auch hier mein Appell: Nicht das Tool den Sowieso-Durchblickern vorenthalten, sondern Verbesserungen vornehmen. - Und, wie gesagt, immer darüber aufklären, wofür sich das Tool überhaupt eignet.
Ja, ein Validator kann kein Grundwissen ersetzen, völlig richtig. Aber zu behaupten, ein Validator kann nicht, nie, nimmer ein nützliches Tool für Anfänger darstellen, verwischt sämtliche Unterschiede und verschweigt Entwicklungen und Möglichkeiten. Wenn ich neuen Mitarbeitern (gutes) HTML beibringe, dann wird der Validator nach ein paar Tagen zu ihrem vertrauten Werkzeug. Dabei gibt es einige praktische Probleme aus den besagten Gründen, aber keine prinzipiellen, unlösbaren.
Mittwoch, 04.08.10 (00:56 Uhr)
Das dachte ich bis vor kurzem auch, bis eine Website über Merkwürdigkeiten eines Parameters namens &lang=xyz gestolpert ist. ⟨ heißt “Left Angle” und sieht auch genauso aus. Obwohl das abschließende Semikolon fehlt, wurde &lang als “Left Angle” interpretiert (etwa so: ⟨=xyz) und der Link funktionierte nicht. Dieser Fehler ist mir jahrelang nicht aufgefallen, weil er nur in einer bestimmten, bis dahin noch nie dagewesenen Konstellation auftritt, in der das & vor lang verschluckt wird.
Für mich ist die Frage, ob man & maskieren sollte, nun definitiv entschieden. Wenn ein Validator empfiehlt, ein & zu maskieren, sollte man es einfach tun. Nicht lange überlegen, dass man es bei &name;= oder &id;= ja weglassen könnte, weil es keine Entities &name; und &id; gibt – einfach machen, konsequent sein, dann hat man Gewissheit und für alle Zeiten Ruh’. Diese Ruh’ hätte ich längst haben können, wenn bei mir schon der Groschen gefallen wäre, als ich vor vielen Jahren mal ein Problem mit einem Parameter namens ©= hatte ... (©=)
Damals wusste ich noch nicht, dass man & auch in Links maskieren muss. Ein Validator hätte mich darauf aufmerksam gemacht, das da was nicht stimmt – den Rest hätte ich dann schon rausgefunden. Deswegen verstehe ich nicht, warum Validatoren so hingestellt werden, als seien sie Höllenmaschinen, mit denen der Laie sich versehentlich selbst entmannen könnte. Ja bitte, die Konfrontation mit der Wirklichkeit ist nunmal nicht immer nett, aber so ist das Leben, da musser durch.
P.S. wie ich eben, dem die Vorschau die Entities im Text zerhauen hat ...
P.P.S. und das ganze gleich nochmal ... ich schick’s jetzt ab, sonst passiert es noch ein drittes mal – und ich sach noch, Werner, mach da ein & hin!
Mittwoch, 04.08.10 (08:33 Uhr)
Um es mal zusammenzufassen: Das Problem liegt nicht in der Implementation einzelner Regeln (ARIA, CSS3, etc.) innerhalb des Validators, sondern darin, dass Ergebnisse immer interpretiert werden müssen. Bei fast allen technischen Analyseverfahren ist das (leider) in der Regel den Experten vorbehalten. Durch die Ampel-Darstellung des Validators verallgemeinert man dieses Problem, um es auch für Laien greifbar zu machen: Grün = alles funktioniert, Rot = kaputt — diese Analogie versteht jeder, ohne sich mit der Materie auseinandersetzen zu müssen.
Leider kann niemand alle von heute auf morgen zu Experten machen, die befähigt (und gewillt) sind, diese Ergebnisse entsprechend zu interpretieren. Ein grünes “Lämpchen” bei der Validierung ist nur bedingt ein Merkmal für Qualität, viele andere Faktoren spielen ebenfalls eine Rolle, die sich nicht über automatisierte Testverfahren erfassen lassen.
Diese Analogie eignet sich besonders für Entscheider, um den Bezug zwischen Validierungs-Ergebnis und Gesamtqualität verständlich zu machen (Es gibt leider noch genug Dienstleister, die damit auf Kundenfang gehen). Es ist wichtig, der Validierung die “unfehlbare Standards-Aura des W3C” zu nehmen. Ja, sie ist wichtig, aber sie ist nur eines der Werkzeuge im Web-Werkzeugkasten. Und wie jedes Werkzeug trägt es helfend zum gefertigten Gesamtergebnis bei, ist aber niemals alleine ausschlaggebend für das Endprodukt.
Mittwoch, 04.08.10 (20:19 Uhr)
Ich fühle mich an Diskussionen mit Michael Preuß auf meinem Blog und aneine Diskussion auf seiner Session beim WordCamp in Berlin erinnert. ;-)
Über das Thema wollte ich auch schon schreiben. Die vielschichtige Problematik ist hier so hervorragend dargelegt, dass ich mir das nun wohl schenken kann.
Gleichwohl ist für mich eine erfolgreiche automatische Grammatik- und Rechtschreibprüfung ein Qualitätsmerkmal. Mag sein, dass ich da einer falschen und veralteten Einstellung erliege, aber das Beispiel mit dem roten Tuch im Kommentar vermengt Validität und Semantik. Code kann semantisch, aber nicht valide sein sowie umgekehrt. Das sind für mich zwei getrennte Paar Schuhe.
Für Semantik gibt es keine vollständig automatisierten Werkzeuge zur Überprüfung. Für die Validität von (X)HTML- und CSS-Code dagegen schon. Das Ärgerliche ist allerdings, dass diese Validatoren leider nicht ebenso schnell weiterentwickelt werden wie neue Webstandards (HTML5, CSS3, WAI-ARIA).
Wenn das Werkzeug Validator aber bei neuen Webstandards versagt, bei den alten dagegen funktioniert, braucht man sich über die Verwirrung bei Laien wie mir sich nicht zu wundern.
Mein Fazit: Neue Validatoren braucht das Land.
In diesem Zusammenhang zum Schluss noch drei Anmerkungen:
Leider ist seit einigen Wochen validome.org offline. Sehr bedauerlich, da dieser Validator richtig gut war. Zudem konnten dort auch sitemap.xml-Dateien validiert werden. :-(
Wenn es einen Zielkonflikt zwischen Validität und dem Einsatz von WAI-ARIA gibt, so versuche ich dem derzeit mit dem Einsatz von JavaScript zu begegnen (siehe hierzu beispielsweise meinen Blogbeitrag unter WAI-ARIA und (X)HTML validieren!). Sobald mein Validator auch WAI-ARIA validieren kann, werde ich diese JavaScript-Krücke mit großer Erleichterung entfernen. Etwas erinnert mich das an die Conditional Comments für den IE, die wir hoffentlich in naher Zukunft auch nicht mehr brauchen werden.
Einen lesenswerten Artikel zum Thema CSS validieren gibt es bei toscho unter Warum man CSS nicht validieren kann.
Freitag, 03.09.10 (06:25 Uhr)
Hallo Dirk Jesse,
danke für diesen Beitrag. Gerade von “konkurrierenden” Webdesignern wird gerne die Validierung als Totschlagargument verwendet um Weblayouts zu diskreditieren. Dieser Artikel wird sicher helfen in Zukunft einen entspannteren Umgang mit dem Thema zu pflegen :-)
Dienstag, 21.09.10 (11:18 Uhr)
Ich finde es schon wichtig, dass Webseiten valide sind. Allerdings gebe ich dir recht, dass Einsteiger mit Validatoren oftmals überfordert sind. Ich habe deshalb letzte Woche 2 Artikel zu diesem Thema veröffentlicht. Im zweiten davon gehe ich auf die 10 häufigsten Fehlermeldungen ein und erkläre, wie man sie beheben kann:
http://www.webmaster-zentrale.de/webentwicklung/html-css/webseiten-richtig-validieren/
Noch wichtiger als die Validität ist es aber natürlich, dass eine Webseite von allen Browsern richtig angezeigt wird. Und bei manchen Dingen, wie z. B. Werbung oder Wordpress-Plugins muss man halt damit leben, dass beim Einbau eine Webseite nicht mehr valide ist. Der zusätzliche Aufwand, diese Dienste valide zu machen, lohnt sich in der Regel nämlich nicht.
Dienstag, 28.09.10 (10:28 Uhr)
Das Problem: Sobald man im Produktiveinsatz mit Webseiten zu tun hat, bei denen aus einem wilden Potpourri aus Bedingungen ein Eintopf aus Trackingpixeln gekocht und in die eigene Seite injiziert werden, ist es mit der Validierung vorbei.
Dann kommt die SEO-Panik, welche bei vielen Firmen einen regelrechten Flurschaden im Internet hinterlassen hat. Ich habe erst vor kurzem wieder ein PRD von einer SEO-Agentur erhalten, welche in ihren Wünschen sich derart streng an Googles Vorgaben hält (bzw. diese doch meist sehr schwammig formulierten “Guidelines” sehr hart als Gesetze auslegt), dass man in das Webdesign von 1998 zurückgezwungen wird.
Ein h1 per CSS durch eine große Titelgrafik ersetzen?! Ist nicht! <h1><img> bitteschön.
Eine Navi mit einem großen CSS-Sprite realisieren? Ist nicht! <ul><li><a><img> bitteschön.
Ich musste in meiner beruflichen Laufbahn nur all zu oft verbissene Grabenkämpfe führen, weil anscheinend (!) viele Werbeagenturen nicht in der Lage sind, vernünftiges Javascript zu schreiben oder keiner sich mal die Mühe macht, den Code für Ads auch valide zu gestalten. Da wird per document. “write” in den Code reingeballert, worauf man gerade Lust hat, und das ganze per HTML-Comment und CDATA zu maskieren hält dann auch keiner für notwendig.
In diesem Sinne: Validierung ist in meinen Augen schön und immer noch wichtig, hat aber nur bei der Basis eines Projektes bestand. Sobald andere Stellen den Code verhunzen (Google Ads, fremdgesteuerte Trackingpixel, Facebook-iFrames, Youtube-Videoframes, etc. pp.) fliegt die Validität als erstes aus dem Fenster.