"Content-Script-Type"-Header

[molily]

Hallo,

Regeln, für die dies nicht gilt, sind graue Theorie: Zwar Teil eines Standards, aber ohne praktischen Nutzen.

Warum werde ich das Gefühl nicht los, dass du dich auf eine nicht nachvollziehbare Art angegriffen fühlst?

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.

Deine Position scheint zunächst angemessen. 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. Der HTML-Standard hat zumeist klare Regeln, da ein Großteil der syntaktischen Regeln in der DTD festgelegt ist. Darüber hinaus gibt es wie gesagt viele andere Regeln. So lässt zu einem gewissen Maß maschinell bestimmen, ob ein Dokument standardkonform ist. Und ein Validator sollte m.M.n. alle maschinell überprüfbaren Regeln überprüfen.

Dennoch gibt es zum einen die besagten Unsinnigkeiten im Standard und zum anderen die Realität der fehlerhaften Browser. 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.

Der Validator-Programmierer muss also anhand irgendeines Kriteriums die gewünschten von den unerwünschten Vorschriften trennen. In diesem Fall sind alle »schlechten« Vorschriften diejenigen, die von den verbreiteten Browsern sowieso nicht bzw. grob fehlerhaft umgesetzt werden, sodass eine Konformität kontraproduktiv wäre. Ich habe nichts dagegen, dass ein Prüfprogramm gemäß eines nachvollziehbaren Kriteriums gewisse Regelungen des Standards durchsetzt und andere vernachlässigt.

Nur, was hat das noch mit Standardkonformität zu tun? »Validierung« sollte sich das nicht mehr nennen. Denn über die Unterscheidung zwischen »guten« und »schlechten« Regeln kann man unterschiedlicher Meinung sein, über die bloße Standardkonformität (tendenziell) nicht.

Zwar Teil eines Standards, aber ohne praktischen Nutzen.

Deshalb habe ich folgendes Modell vor Augen:
1. Erst einmal überprüft ein Prüfprogramm möglichst alle maschinell überprüfbaren Regeln.
2. Dadurch kann es dem Anwender kompetent und ehrlich mitteilen, in welchen Punkten das Dokument vom Standard abweicht.
3. Jetzt ist der Anwender gefragt, die Abweichungen zu beurteilen. Was für Regeln sind es, die missachtet werden? Was spricht dafür oder dagegen, ihnen zu folgen? Sollte man sie besser missachten? Hier sollte ein Prüfprogramm eine entsprechende Dokumentation bereitstellen, z.B. auch zur Problematik »Content-Script-Type«. Diese Dokumentation könnte begründete Empfehlungen beinhalten, welche auf die Browser-Realität hinweisen.

Der Anwender kann sich dann immer noch über den Standard hinwegsetzen - wichtig ist, dass er genau weiß, was er da tut und welche Konsequenzen es hat. Das verstehe ich unter einem kritischen Herangehen an den HTML-Standard (wer die Regel hinreichend kennt, kann sie brechen).

Bei diesem Modell darf sich das Prüfprogramm zurecht Validator nennen, weil es die Gültigkeit eines Dokuments hinsichtlich des Standards gewissenhaft überprüft. Ob diese Fehlermeldung, die in der Dokumentation sozusagen wieder aufgehoben würde, nun verwirrt, ist für mich nicht entscheidend. Es geht darum, dass nicht jeder Entwickler eines Prüfprogramms entscheiden sollte, was standardkonform heißt und was nicht.

Wenn der Entwickler hingegen absichtlich nach eigenem Ermessen gewisse Regeln des Standards links liegen lässt und trotzdem meint, das Prüfprogramm ermittle, ob ein Dokument standardkonform sei, dann ist er unehrlich und klärt den Anwender nicht hinreichend auf. Ich will einem »Validator« ein Dokument geben und es soll mir exakt sagen, ob und inwiefern es standardkonform ist - ich will nicht, dass mir ein Entwickler seine Kurzfassung bzw. Interpretation des Standards als Standard verkauft.

Dieses Problem zeigt sich etwa darin, dass sich mit dem Aufkommen von Validome und dem XHTML Schema Validator viele gefragt haben: Ist mein Dokument nun standardkonform oder nicht? Ein und dasselbe Dokument wird in drei sogenannten Validatoren anders bewertet. Nun beruhen die Unterschiede momentan weniger darauf, dass die Entwickler »schlechte« Regeln ignorieren, sondern darauf, dass sie entweder keine Notwendigkeit sehen, alle überprüfbaren Regeln zu überprüfen, oder darauf, dass die DTD-Überprüfung an sich problematisch ist. 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.

Mathias