Tag molily.
Das verstehst du falsch. Nach einiger Auseinandersetzung mit verschiedenen Validatoren betrachte ich diese Frage aus der Sicht derer, die Validatoren entwickeln müssen und dabei möglichst methodisch korrekt vorgehen wollen.
Dabei stellt sich dann doch die Frage, was "konform" bedeutet. Du schriebst in einem deiner vorhergehenden Postings, dass sich der "Content-Script-Type"-Header nicht aus der DTD-Grammatik herleiten lasse. Der Unterschied zwischen validem und standardkonformem HTML ist recht gut in der Hilfe zum W3C-Validator beschrieben, in der Einleitung heißt es u.a.:
„Validation is, however, neither a full quality check, nor is it strictly equivalent to checking for conformance to the specification.“
Damit denke ich sollte eines der größten Missverständnisse zumindest beim Gebrauch des W3C-Validators ausgeräumt sein: Validität ist nicht automatisch Konformität zum Standard. Der Selfhtml-Validator scheint mir einen anderen, höheren Anspruch zu verfolgen, nämlich die Prüfung auf Standardkonformität (zumindest kann man es so auf der Heimatseite validome.org herauslesen, ich gehe mal davon aus, dass diese Aussagen auch auf den Selfhtml-Validator zutreffen).
Die Zwickmühle rund um Content-Script-Type weist aber auf ein grundsätzliches, ziemlich gewichtiges Problem von Validatoren hin. Ein Validator behauptet von sich, zu prüfen, ob ein Dokument standardkonform ist.
Genau das scheint mir der Irrtum zu sein, wie ich eingangs versucht habe, darzustellen. "Valide" heißt stark vereinfacht "der DTD entsprechend", standardkonform hingegen ist weitaus mehr.
Dennoch gibt es zum einen die besagten Unsinnigkeiten im Standard und zum anderen die Realität der fehlerhaften Browser.
Könnte es denn nicht sein, dass dieser Teil des Standards deshalb nicht den Weg in die DTD gefunden hat, weil er zumindest im Moment unsinnig ist?
Was ist nun angesichts dessen die Aufgabe des Validators? Du plädierst dafür, dass ein Validator nicht nüchtern (erst einmal) die Kriterien des Standards überprüft, sondern der Validator-Entwickler zwischen »guten« und »schlechten« Vorschriften des Standards unterscheidet. Der Validator prüft dann die Einhaltung der »guten« Vorschriften und lässt Verstöße der »schlechten« Regeln kommentarlos durchgehen, während das Dokument den Stempel »standardkonform« bekommt, obwohl es wissentlich nicht vollständig standardkonform ist.
Trotzdem ist das Dokument valide (konform zur DTD), nicht mehr, aber auch nicht weniger. Einen Stempel "standardkonform" dürfte es nach dem Ergebnis dieser Diskussion nicht geben und gibt es meines Wissens auch nicht.
Ich habe nichts dagegen, dass ein Prüfprogramm gemäß eines nachvollziehbaren Kriteriums gewisse Regelungen des Standards durchsetzt und andere vernachlässigt.
So tut es der W3C-Validator, siehe What is Markup Validation?, sein nachvollziehbares Kriterium ist die zur jeweiligen (X)HTML-Version gehörende DTD.
Nur, was hat das noch mit Standardkonformität zu tun? »Validierung« sollte sich das nicht mehr nennen.
Genau darin liegt m.E. dein Denkfehler.
Ich will einem »Validator« ein Dokument geben und es soll mir exakt sagen, ob und inwiefern es standardkonform ist
Dann mache einen Bogen um den W3C-Validator und bediene dich bei Validome.
ich will nicht, dass mir ein Entwickler seine Kurzfassung bzw. Interpretation des Standards als Standard verkauft.
Wer tut das?
Aber die Unterscheidung von praktisch sinnhaften und unsinnigen Regeln kann m.M.n. dazu führen, dass weitere subjektive Definitionen von »Was ist standardkonform?« auftauchen. Und dem gegenüber bin ich äußerst skeptisch.
Ich denke, dass man mit der Unterscheidung "valid" und "standardkonform", wie ich sie versucht habe zu skizzieren, durchaus gut leben kann.
Siechfred