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.

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.

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 :-)

Ü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.

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.

Die automatische Rechtschreibprüfung von Microsoft Word oder Open Office mit dem vorinstallierten Standardwörterbuch [sagt genauso wenig] über meine Fähigkeiten [aus], gute und fehlerfreie Fachtexte zu schreiben.

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.

Man kann darüber streiten, ob man für jedes unmaskierte “&”-Zeichen in einer URL ein Fass aufmachen muss.

Das dachte ich bis vor kurzem auch, bis eine Website über Merkwürdigkeiten eines Parameters namens &lang=xyz gestolpert ist. &lang; 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 &copy= 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!

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.

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.

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.

Im Prinzip ist es ein Unding, daß die Existenz von Validatoren allgemein bekannt ist, denn nicht jeder kann sie bedienen und korrekt lesen.

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.

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.

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.

»Validität ist kein Qualitätsmerkmal!«

Wie du in der Diskussion präzisierst, meinst du das gar nicht so.

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.

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

Ich mache es mir da einfacher: Standardskonformität ist ein Qualitätsmerkmal unter vielen.

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?

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.

Die Prüfung ist wichtig zur Selbstkontrolle, zur Vermeidung und dem Auffinden von Flüchtigkeitsfehlern und somit ein Entwicklerwerkzeug.

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.

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.