Oliver Heeger hat in seinem Blog den BIENE Preisträger Manufactum auf Validität geprüft, war mit dem Ergebnis nicht zufrieden und versucht es an die herkömmliche Bedeutung einer Goldmedaille rückzubinden: Gold heißt für mich GOLD, 10 von 10 Punkten, besser geht’s nicht, Top of the Pops, 1a, FEHLERFREI!!!
Den W3C Validator zu nutzen, um eine Webseite auf ihre Validierung zu prüfen, ist ja für uns alle Tagesgeschäft, wir sollten aber, wenn wir eine Webseite prüfen, uns auch das Prüfprotokoll genau ansehen und die aufgeführten Fehler in einen entsprechenden Kontext setzen. Und weil es mir gerade Spass macht, greife ich ein wenig plagiathaft dabei auf Wittgensteins Tractatus Logico-Philosophicus zurück – sehr bescheidene Reminiszenz an mein Salzburger Philosophiestudium. 😉
Im Quellcode ist nichts zufällig
Sehen wir uns doch mal genauer an, was im Quellcode bei Manufactum nicht validiert. Oliver Heeger hat das nur kurz angerissen, hier ein wenig detailierter: Nicht-maskiertes Javascript (1x), Schachtelungsfehler (5x) und Doctype-Warnungen (25x). Führt man die Fehler und Warnungen des Validators so auf, relativiert sich schon einiges.
Geht man nun noch genauer an die einzelnen Fehlerquellen ran, kann man gut festmachen, woher die Fehler kommen. Gut, das nicht-maskierte Javascript muss schlicht maskiert werden, das tritt an einer Stelle auf und ist schnell behoben. Spannender wird es bei den Doctype-Warnungen. Fast ein Klassiker dürfte es sein, das Meta-Element von Google in der XHTML-Variante schlicht zu kopieren. Die Seite selbst nutzt ja den Doctype HTML 4.01 Strict, daraus ergeben sich sämtliche Doctype-Warnungen. Ein weiterer, mir sehr bekannter Klassiker ist das Input-Feld type=hidden, das xhtml-konform mit Slash geschlossen und so eingebaut wird. Höchstwahrscheinlich kommen die Formularelemente xhtml-konform aus einer dynamischen Engine.
Für die Überschriften wird ein System verwendet, dass den Inhalt der Überschrift aus dem CMS in eine Grafik rendert. Leider schließt diese Grafik auch wieder mit einem Slash xhtml-konform ab und wirft daher eine Doctype-Warnung. Auch hier vermute ich, dass dieses System die Grafik automatisch ins Template packt, eventuell kann man im Backend an die Generierung rangehen und den Slash entfernen. Wenn es im Template dynamisiert ist, dann geht das quasi sofort. 🙂 Da die Überschrift natürlich mehrmals auf der Webseite eingesetzt ist, ergeben sich daraus dann mehrfache Warnungen. Auch br-Elemente sind immer mal wieder xhtml-konform geschlossen, aber – soweit ich das erkennen kann – immer nur in Teiltemplate-Kontexten. Daraus lässt sich schließen, dass hier wohl ein Editor, der xhtml-konform arbeitet, im Einsatz ist.
Bei den Schachtelungsfehlern, dass etwa in ein p-Element ein div-Element verschachtelt ist – da kommen sich zwei Blockelemente in die Quere -, bin ich noch unsicher, wie die wirklich zustande kommen. Sie treten innerhalb Teiltemplates auf und das p-Element umschließt dabei stets andere Blockelemente wie div. Zuerst dachte ich, dass das p-Element eventuell durch den Einsatz eines Editors entsteht, aber es ist eher unwahrscheinlich, dass im Editor fest benamte div-Elemente eingebaut sind. Okay, möglich ist immer alles. 🙂 Sieht man sich jedoch den gesamten Aufbau der Seite an, fällt diese Block-in-Block-Schachtelung eher singulär auf. Interessant wäre für mich, wie das genau in der Templategenerierung passiert.
Der Quellcode gehört nur zur Aufgabe, nicht zur Lösung
Zugegeben das ist jetzt Wittgenstein sehr zugespitzt formuliert, aber es soll darauf hinweisen, dass Quellcode Aufgaben erfüllt und nicht Selbstzweck ist. Es ist natürlich wunderbar, wenn die Aufgabe soweit erfüllt wird, dass sie auch gelöst und valide ist. 🙂 Sehen wir uns jedoch die Validierungsprobleme von Manufactum genauer unter diesem Aspekt an, fallen uns zwei Stichworte ein: Dynamisierung und Fremdsysteme. Manufactum wurde von der Agentur neuland bereits 2007 realisiert, die sich auf Shopsysteme spezialisiert und den Relaunch auf der Basis von spring/hibernate realisiert hat. Abgesehen davon, dass Shopsysteme lange Zeit – wer schon damit Erfahrung gewonnen hat, wird mir zustimmen – ohnehin oft eine Webstandards-Wüste waren, scheint die Kombination von Spring– und Hibernate–Framework in der Ausgabe richtig gut anpassbar zu sein. Leider kenne ich beide Frameworks nicht, aber ich nehme an, dass da – sieht man sich die Kommentare an – auch ein Templatesystem zur Verfügung steht. Und was da an Teiltemplates ausgegeben wird, ist durchaus sehr semantisch, weitgehend reduziert und standardkonform.
Templatesysteme bringen uns endlich Dynamisierung und daher kann man die Validierungsprobleme bei Manufactum auch sicherlich schnell beheben. Nimmt man die Fehler und Warnungen nur 1x, sieht das dann wirklich schon fast beiläufig aus: Nicht-maskiertes Javascript (1x), Schachtelungsfehler (2x) und Doctype-Warnungen (5x). Es ist schlicht wichtig, sich die Anzahl der Fehler im Hinblick auf den dynamischen Aspekt anzusehen. Schließlich wird der schließende Slash dann x-mal durch die mehrmalige Templateeinbindung ausgegeben. Andererseits muss der Slash dann auch nur an einer Stelle in einigen Teiltemplates entfernt werden, auch so ein wunderbares Ergebnis des Templating.
Und außerhalb der Validität ist alles Zufall?
Nein. 🙂 Aber seit Jahren warten wir auf BIENE-Preisträger die hochkomplexe, dynamische Systeme barrierefrei gestalten. Und wer mit hochdynamischen Systemen täglich arbeitet, wird mir wieder zustimmen, dass das für die Barrierefreiheit zweierlei bedeuten kann: einen Fluch und einen Segen. Zum einen wird es mit Templatesystemen und Engines etwa für Formulare einfacher, an genau abgegrenzten Stellen Barrierefreiheit einzuarbeiten und in hoher Dynamik dann auch verlässlich auszugeben und zur Verfügung zu stellen. Andererseits steigt durch hochdynamische Systeme auch die Fehlerhäufigkeit, die Komplexität von Modulen und Techniken oder auch die Einbindung von Fremdanteilen. Mitunter hat man auf etliche Module und Anteile dann kaum oder gar keinen Zugriff mehr.
Was bleibt? Oliver Heeger hat natürlich recht, Validitätsprobleme einzuklagen. Aber – und da sollten wir einfach mal mindestens einen Schritt in der Argumentation zurückgehen – angesichts dessen, was an Dynamik hinter Manufactum steht, sind die Validitätsfehler und -warnungen doch minimal. Das finde ich spannend an so einem Preisträger, zu verfolgen und mir genau anzusehen, wie er mit diesen komplexen Anforderungen im Hinblick auf Webstandards und Barrierefreiheit umgeht. Und es gibt ja noch mehr Preisträger dieses Jahr, die mit hochdynamischen Systemen arbeiten. Eben genau auf solche Ergebnisse und Preisträger haben wir doch gewartet oder?!
Insofern kann man Wittgenstein nur zustimmen: Einen a priori wahren Quellcode gibt es nicht. Wir müssen ihn immer wieder mit der (dynamischen) Wirklichkeit vergleichen.
Update
Mathias Schäfer hat hier in seinem Kommentar sehr richtig darauf hingewiesen, dass es sich bei p > div nicht um Schachtelungsfehler handelt, sondern das schliessende p in HTML 4 optional ist und daher im Validator nur der Hinweis auf ein schliessendes p steht, das keine Entsprechung mehr zu einem öffnenden hat.
Hallo Sylvia, danke für deinen Kritischen Kommentar. Leider hat sich ja sonst kein anderer aus der „Szene“ dazu geäußert.
Aber wie gesagt, ich bin der, der sich mit barrierefreiheit am wenigsten auskennt. Für mich ist der Quellcode allerdings das was hinter allem steht und deshalb gerade bei einem „Gold“ Gewinner einwandfrei seien sollte.
Valider Code ist schließlich das einfachste Kriterium das man an den Anforderungen erfüllen kann (und das einfachste Kriterium über das sich so Leute wie ich aufregen können). Und valider Code gehört nun mal zur Zukunftssicherheit. Was ist wenn morgen ein JAWS,iPhone,wasauchimmer update rauskommt welches sich an unescapetem JS verschluckt?
Ich gebe dir aber trotzdem recht wenn du schreibst: „Auf sowas haben wir gewartet“. Haben wir!
Hallo Oliver,
wir haben auch im Webstandards-Bereich immer wieder die Validitätsdiskussion. Grundsätzlich stimme ich Dir ja vollkommen zu, dass valider Code zum einen einfach – kommt natürlich auf das System an, dass den Code produziert – darauf bin ich ja in meinem Kommentar etwas genauer eingegangen – ist und eine gewisse Zukunftssicherheit bietet.
Validität wird auch in Dokumenten wie WCAG2 oder BIENE als Kriterium explizit angeführt, der BITV-Test ist da einer der strengsten. Aber Validität ist für Barrierefreiheit nur ein Zeichen, dass standardkonform oder robust – wie es im WCAG2 so schön heisst – gearbeitet wurde. Es ist eine gute Grundlage, aber auch nicht valide Webseiten können barrierefrei sein.
Mir ist wichtig, dass ich hier nicht missverstanden werde. Es ist schon wichtig validen Code zu erarbeiten, aber wir sollten bei unseren Analysen von Webseiten, die nicht validieren, halt auch den Kontext genauer betrachten, warum es diese Fehler gibt.
Ich halte nicht soviel davon, Preise und Preisträger nach ihren gewonnen Farben oder Formen zu bewerten. 🙂 Ich sehe mir nur Webseiten auf Barrierefreiheit an. Und bei Manufactum sehe ich mir das unter dem Aspekt eines hochdynamischen Shopsystems an. Dass soll jetzt nicht mehrerlei Mass bedeuten, sondern schlicht eine besondere Kontextbetrachtung und -setzung.
Auch wäre es spannend mal diese Robustheits- und Zukunftsicherheits-Diskussion zu führen. Was bedeutet das etwa unter dem aktuellen Aspekt von noch fliessenden Standards wie Microdata oder HTML5. 😉
Interesseant was @sprungmarker schreibt – Der Quellcode gehört nur zur Aufgabe, nicht zur Lösung http://ow.ly/UgGj
This comment was originally posted on Twitter
@Oliver: Es hat sich niemand aus der „Szene“ geäußert, weil wir schon über diese Diskussion lange hinaus sind bzw. sein sollten. Die meisten langweilt diese Diskussion, was ich verstehen kann. Validität ist schön, sagt aber nicht wirkllich viel aus, ohne daß man sie interpretiert.
Es gibt wichtigere Diskussionen, Debatten und Tests, als sich immer wieder an einem, zwei oder drei Fehlern im Validator hochzuzihene – solange der Code grundsätzlich gut und durchdacht ist.
Wenn ich ARIA-Roles meinem Code hinzufüge, ist meine Seite nicht mehr valide. Nicht, weil ich zu doof wäre, sondern weil der Validator der Entwicklung hinterherhinkt.
Ich hoffe das in html 5 noch einiges verbessert, vereinfacht oder universeller gestaltet wird. Warum z.B nicht <li href=““></li> zulassen oder href gleich zum universalattribut von inline- oder sogar block- level Elementen machen. Das würde einiges einfacher, kürzer und sicherer machen. Dann bräuchten die coder auch keine onklick events mehr auf div’s legen;) Aber selbst in Html 5 wird die Validität wichtig sein, gerade bei falsch verschachtelten oder nicht geschlossenen Tags. Ich fande z.B. die Einführung von selbst schließenden Tags in xhtml unglaublich wichtig um die Maschinenlesbarkeit zu erleichtern – und das ist es ja warum es mir geht. Google fällt regelmäßig darauf rein – warum nicht auch Endgeräte?
Nixdestotrotz, ich verstehe dich und du verstehst mich. Ich bin Validitätsfreak, und daran wird sich auch an Html^x nichts ändern. Vielleicht sollten wir das mal in der runde beim bpse besprechen?
Es ist gut, dass du versuchst, die Validator-Ausgaben genauer zu analysieren, aber ich würde noch viel radikaler behaupten: Die gegenwärtigen Werkzeuge zur Validierung liefern keine adäquaten Resultate. Und das sage ich als großer Verfechter der Qualitätssicherung.
Validierung ist kein Selbstzweck. Man muss wissen, was diese Werkzeuge tun, wofür man sie lohnend anwenden kann und wie Fehler zu deuten sind. Darüber hinaus muss man wissen, wie Validität bzw. Standardkonformität mit Kompatibilität und Barrierefreiheit zusammenhängen.
Der W3C-Validator verwendet bei HTML-4.01-Dokumenten einen SGML-Parser und validiert gegen eine SGML-DTD. Das ist völliger Unsinn, weil es nie einen relevanten Browser gab, der gemäß SGML Dokumente geparst hat. Über tatsächliche, praktisch relevante Fehler kann ein so arbeitender Validator keine Auskunft geben. Jetzt könnte man einwenden: Aber Standardkonformität ist trotzdem gut. Klar, nur wurde dieser Standard im Web nie umgesetzt.
Übrigens ist
<p><ul>kein Verschachtelungsfehler. Da wird nämlich nichts verschachtelt. Im DOM ist das ul-Element ein Geschwister, kein Kind des p-Elements. Das liegt daran, dass der End-Tag des p-Elements optional ist und das Element bei dessen Weglassen automatisch beim nächsten Blockelement geschlossen wird. Deswegen stört sich der Validator auch nicht an der Verschachtelung, sondern fragt sich nur, was das schließende</p>soll.Ferner hat
<meta />in HTML4 *theoretisch* eine ganz andere Bedeutung, als jeder Browser es verarbeitet und sogar als es in XHTML definiert ist. Deswegen redet der Validator auch so kryptisch: »NET-enabling start-tag requires SHORTTAG YES« oder meint zu dem »<« von<meta />: »character data is not allowed here«. Das ist natürlich gaga und nur zu erklären, wenn man SGML-Regeln kennt und versteht, wie ein SGML-Parser mit/<umgeht. – Wie gesagt: Kein Browser arbeitet so.Alle der vom W3C-Validator aufgezeigten Fehler sind praktisch irrelevant. Weil Browser einfach nicht so arbeiten und es nie getan haben. Anstatt: Korrigiert euren Code und passt ihn den Standards an, wird derzeit das Gegenteil gemacht: Der Standard wird geändert und der Browserrealität angepasst. Dieses vorhaben nennt sich … *trommelwirbel* … HTML5.
Validiert man Manufactum gemäß HTML5
<http://html5.validator.nu/?doc=http%3A%2F%2Fwww.manufactum.de%2Fhome.html>, so ist– XHTML-Syntax für selbstschließende Start-Tags erlaubt, weil die Browser sie akzeptieren
– Unmaskierte End-Tags innerhalb von
<script> ... </script>sind erlaubt, weil die Browser ohnehin erst beim</script>das Element schließen, nicht schon bei »</«, wie es noch im HTML-4-Standard stehtFehlerhaft sind natürlich weiterhin die überflüssigen
</p>-Tags, weil es dazu keine entsprechenden<p>-Tags gibt. Diese können ein praktisches Problem sein, weil z.B. WebKit daraus ein weiteres leeresp-Element erzeugt.Fazit: HTML4-Validatoren (ergo SGML-Validatoren) sind unbrauchbar nach heutigen Anforderungen. Aussagekräftige Validierung ist erst mit HTML5 möglich.
Natürlich kann es auch sinnvoll sein, sich strengen XHTML-Strict-Regeln zu unterwerfen und dann gemäß XML-Schemata zu validieren. Das hat zwar wenig mit der Browserrealität zu tun, aber Qualitäts- und Syntaxregeln lassen sich effektiv prüfen und es ist eine Verarbeitung als XML möglich.
Zur Ergänzung noch ein Artikel zur strengen HTML-4-Validierung, wo ich die Fallstricke von SGML genauer anspreche: http://molily.de/weblog/html4-validierung
Bei @sprungmarker einen längeren Kommentar zur HTML-Validierung gepostet: http://bit.ly/7sJ3Cz Kurz: Vergesst HTML4-Validatoren. Go #html5
This comment was originally posted on Twitter
[…] Dieser Eintrag wurde auf Twitter von Sylvia Egger, Martin Ladstätter erwähnt. Martin Ladstätter sagte: Danke und daher Lesebefehle 😉 RT @sprungmarkers: Der Quellcode gehört nur zur Aufgabe, nicht zur Lösung http://bit.ly/4QY5Ji T […]
@Oliver
Validitätsfreak ist ja ein interessanter Begriff. Nun in HTML 5 kann, aber muss man nicht mehr Attribute explizit mit einem Wert versehen, wie etwa required. Da wird sich schon was ändern. Ich fand
selected="selected"auch immer etwas hart an der Grenze der Retundanz.Maschinenlesbarkeit – gut über diesen Zusammenhang lass uns beim nächten #bpse sprechen. 🙂
@molily
Stimmt, ich bin zu validatorhörig in meiner Argumentation, aber ich nehme halt da auch einen anderen Blickwinkel ein, wenn ich schlicht mich mit dem gegeben Prüfprotokoll abfinde und eher versuche, in der Templatepraxis Abläufe zu durchleuchten. Ist ja nicht so, dass uns das alles noch nie passiert wäre – sieht man sich die erwähnten Fehler und Warnungen an.
Danke Dir dafür, ich lese gerade Deinen erwähnten Artikel durch. Ich muss auch gestehen, dass ich im Validierungsbereich seit Jahren keine HTML4-Seiten mehr hatte und deswegen auch zu xhtml-streng denke. Deine Anmerkung zu dem Verschachtelungsthema stimmt ja, hab ganz verdrängt, dass das schliessende p optional in HTML4 ist. Hm – ist dann im DOM in XHTML bei schliessendem p das DIV – was ja nicht valide ist – immer noch auf der Geschwisterebene?
Das ist schon etwas unschön tricky? Ich werde das jetzt gleich mal nachlesen …
Gut, die Tiefe der Validierungsproblematik kenne ich so nicht, ich versuche aufgrund meines bisherigen Standardverständnisses die Aussagen des Validators einzuordnen und zu bewerten. Im Grunde bin ich ja, auch wenn Du einen anderen Blickwinkel einnimmst, auf durchaus ähnliche Ergebnisse gekommen, halt aus der Templatepraxis gespeist.
Ob sich in (X)HTML5 die Aussagekraft des Validators positiv verändern wird, kann ich nicht beurteilen. Aber wünschenswert ist es allemal. Ich lass mich da gerne positiv überraschen.
@Jens
Du magst recht haben, mit dem Thema und der Langeweile – ich habe auch lange überlegt, ob ich noch was dazu sagen soll. Vor allem weil Validität wohl einen hohen Stellenwert bei der nicht so barrierefrei-firmen Gemeinde hat. Oliver hat das ja auch gut zugespitzt, Validität ist für ihn quasi so eine Art Grundkonsens, da kann sich jeder Entwickler Richtung Barrierefreiheit bewegen. Was aus seiner Sicht verständlich ist, aber wenn man sich intensiver mit dem Thema Barrierefreiheit beschäftigt, weiss man, dass das eben nur ein Thema unter vielen ist und letztlich nicht mehr wirklich präsent, wenn man sich mal eingearbeitet hat über die Jahre.
Das Stichwort ARIA ist halt grade das virulenteste Beispiel, aber ist für mich ja nur ein Hinweis darauf, dass Standards eben fliessender, offener und unfertiger werden. Was auch immer das dann für die Standard-Praxis bedeuten wird. Auf keinen Fall ist der Weg etwa, aus CSS-Klassen mit Javascript wieder ARIA-Atribute zu machen. Wir müssen uns einfach daran gewöhnen, dass Validatoren – das betont ja auch Mathias Schäfer – nicht mehr auf der Höhe der Zeit sind … Freilich müssten sich dann auch die Spezifikationen und Dokumente ändern, die Validität fordern.
Darf ich einwenden, dass der Validator nicht mit der Validität selbst verwechselt werden darf?
Validität ist ein Zustand, bei dem das Markup der Spezifikation entspricht. Wir akzeptieren nichts unter 100 Prozent. Ein Validator ist ein Computerprogramm. Es wurde also von einem Menschen programmiert und enthält eine endliche Anzahl von validen Möglichkeiten. Überschreitet mein Markup diese Begrenztheit eines Validatorprogramms, dann bedeutet das nicht unbedingt, dass das Markup deshalb nicht valide ist, dennValidität ist ja die Übereinstimmung mit der Spezifikation selbst und nicht mit deren Interpretation des Validator-Programmierers. Validatoren erzeugen oft Scheinexaktheit. Sie prüfen exakter, als die Spezifikation spezifisch ist. Sonst würden Webseiten ja in allen Browsern identisch aussehen.
Ich benutze role- und rel-Attribute, die im Validator Probleme machen. Solange die Attribute aber syntaktisch korrekt angewandt sind, verzichte ich nicht darauf, nur weil der Programmierer des Validators noch nie davon gehört oder sie einzubauen vergessen hat. Der Validator sollte inhaltlich unbekannte aber syntaktisch korrekte Elemente genauso ignorieren, wie es Browser und Spider tun. Das role-Attribut fällt nicht durch, weil es nicht der XHTMl-Spezifikation entspricht, sondern weil der Validator es nicht kennt.
Auch bei verschachtelten Tags — besonders bei rein semantischen — gibt es Fehlalarme, etwa bei einem in einem abbr-tag eingeschlossenem span-lang-tag.
Ich verstehe nicht, warum ich auf einen Validator hören soll, wenn:
1. die Syntax der Spezifikation entspricht;
2. das Markup in allen Browsern funktioniert;
3. das Markup auch Maschinen nicht stört oder ihnen bei der Textexegese sogar hilft.
[…] Über den Umgang mit dem Validator: Der Quellcode gehört nur zur Aufgabe, nicht zur Lösung […]
Ich halte es immer dann für eine faule Ausrede, dass eine Seite nicht 100%ig validieren muss, wenn es an so banalen Dingen wie einer Vermischung von <br> und <br/> scheitert. Dabei sind das Symptome für eine Unkultur, die ich schon seit längerem kritisch beobachte: das Online-Shops, CMS usw. programmiert werden, indem Frameworks zusammengeharkt werden, die aus Frameworks zusammengeharkt wurden, die auf irgendwelchen Frameworks aufsetzen, welche aus irgendwelchen Frameworks geforkt wurden. Das ganze wird dann als Profisoftware angeboten, obwohl es der Profi nicht hinbekommen hat, den Output der Module z. B. mittels $output=str_replace (‚<br />‘, ‚<br>‘, $output) oder umgekehrt zu vereinheitlichen. Und dann macht man’s wie in einem alten Microsoft-Witz: Man erklärt einen Fehler zum Standard und den Standard zu einem Fehler.
Ohne mich. Ich bin mit Sicherheit kein Standardista und nehme inkauf, dass der CSS-Validator mit „border-radius“ und „box-shadow“ noch nichts anfangen kann, aber das kann ich mit guten Argumenten begründen. Alles andere bezeichne ich als das, was es ist: mein Fehler.
André
@André
Das Szenario, das Du entwirfst ist nachvollziehbar und durchaus nicht unüblich. Es ist etwa leicht zu finden in Blogsoftware wie WordPress, das dann mit Plugins aufgebohrt wird und die Plugin-Entwickler nicht standardkonform arbeiten. Obwohl man hier wieder einhaken muss, dass grade die WordPress-Entwicklung sehr bemüht ist – auch die Entwickler – standardkonform, valide und robust in die Zukunft zu entwickeln. Den Eindruck habe ich gewonnen, sehe ich mir immer wieder die neuesten Plugins an.
Ich gebe Dir mit dem Hinweis recht, dass man das einfach durch eine Ersetzungsroutine laufen lassen kann. Aber – ich kenne das durchaus auch – es geht ja auch um Lernprozesse, jedesmal zum Programmierer zu gehen und diese Routinen einzufordern, kann auch anstrengend sein.
Besser wäre es, Programmierer würden das mehr verinnerlichen, valide und standardkonform zu arbeiten.
@ Helen
Du darfst hier alles einwenden. 🙂
Sicherlich kann man Validität auch vom Validator abkoppeln und es stimmt, dass Validität sich primär auf das umgesetzte Markup im Verhältnis zur Spezifikation bezieht. Aber sekundär muss Validität im Arbeitsprozess auch überprüfbar sein – wir arbeiten ja auch mit prozesshaften Plugins wie HTML-Validatoren, die uns beim Arbeiten schon anzeigen, ob unser Code valide ist. Und diese Plugins müssen auch auf immer individuell nachjustiert werden, sie validieren je nach Einstellung.
Es ist also nicht so, dass wir nicht auch wüßten, welche Elemente kritisch sind für eine Validierung und den Valdiator und welche nicht. Ich sehe das mittlerweile auch sehr im Fluß und weiss, wann und warum mein Code nicht validiert. Und damit meine ich Code, der durchaus den aktuellen Spezifikationen folgt, aber auf Validatoren trifft, die diesen aktuellen Zustand noch nicht widerspiegeln.
Es geht ja auch nicht darum, auf einen Validator zu hören, sondern ihn als Werkzeug zu sehen, um für seinen Code eine Zustandsbeschreibung zu erhalten. Und in unserer Diskussion grade geht es ja nicht um solche Spezialfälle wie rel-Attribute oder WAI-ARIA, sondern um schlichte gängige Fehler im Markup. Und die gibt es nun mal und dafür sind Validatoren ein hinreichendes Werkzeug, um die festzustellen.