Sinn und Unsinn von Validatoren
jmk
- html
Hallo Forum,
vor einigen Stunden bin ich im Zusammenhang mit der Problematik um das W3C und die "WHAT WG" über einige sehr kritische Auseinandersetzung mit dem Validator des W3C gestoßen.
Es wurde die Meinung vertreten, dass der W3-Vali. verschiedene Syntaxfehler nicht aufdecken könne. Insbesondere im Zusammenhang mit XHTML und XML gebe es einige Probleme.
Die Programme von Validome (http://www.validome.org/) und Christoph Schneegans (http://schneegans.de/sv/) scheinen hingegen einen besseren Ruf zu haben.
Ich habe darauf hin ein XHTML-Doc. welches vom W3-Vali als gültig gekennzeichnet wurde, prüfen lassen und tatsächlich wurde ein angeblicher systematischer Fehler entdeckt, der vorher unentdeckt blieb.
Meine Frage ist nun, in wie weit man diesen Tools generell vertrauen kann. Mir ist sehr wohl bewusst, dass so ein Programm niemals missbrauchte table-Elemente oder Ähnllches aufdecken kann, jedoch hatte ich erwartet, dass syntaktische Fehler ordentlich registriert werden. Ich behaupte über ordentliche Kentnisse in HTML/XHTML zu verfügen. Ich setze einen Validator gerne ein, um nach der Fertigstellung eines Dokumentes nach Flüchtigkeitsfehlern und Ähnlichem zu suchen. Für diese Aufgabe scheinen die Programme aber nur bedingt geeignet zu sein.
Meine Frage ist, in wie weit man den verschiedenen Validatoren vertrauen kann und wann es eurer Meinung nach Sinn macht einen Validator zu "konsultieren." bzw. wann es völliger Quatsch ist.
Vielen Dank für eure Antworten!!
also ich benutze den w3c validator auch als qualitätsnachweis. Wie soll man sonst einem Kunden nachweisen das man zumindest fehlerfrei gearbeitet hat.
Ausserdem benutze ich Ihn auch um Flüchtigkeitsfehler zu finden.
gruesse
marc
Tach.
also ich benutze den w3c validator auch als qualitätsnachweis. Wie soll man sonst einem Kunden nachweisen das man zumindest fehlerfrei gearbeitet hat.
Damit weist du lediglich nach, daß du keine syntaktischen Fehler gemacht hast (siehe auch Zitat 136). Über die Qualität deiner Arbeit sagt das nicht viel aus.
also ich benutze den w3c validator auch als qualitätsnachweis. Wie soll man sonst einem Kunden nachweisen das man zumindest fehlerfrei gearbeitet hat.
Damit weist du lediglich nach, daß du keine syntaktischen Fehler gemacht hast (siehe auch Zitat 136). Über die Qualität deiner Arbeit sagt das nicht viel aus.
Nun, ist die Syntax OK, freut sich der Mensch. Oft ist dann auch die Semantik ganz brauchbar. ;)
habe d'ehre jmk
Ich habe darauf hin ein XHTML-Doc. welches vom W3-Vali als gültig gekennzeichnet wurde, prüfen lassen und tatsächlich wurde ein angeblicher systematischer Fehler entdeckt, der vorher unentdeckt blieb.
Mich würde der angemeckerte Codeabschnitt interessieren.
man liest sich
Wilhelm
hallo,
Mich würde der angemeckerte Codeabschnitt interessieren.
Gerne, hier der Output von Validome:
,---------------------------------------------------------------------
| Das Dokument ist nicht valides
| XHTML 1.0 Strict
| Benutzte Zeichenkodierung:
| utf-8
|
| Quelle:
| Zeichenkodierung aus XML-Deklaration
|
| Fehler (22)
|
| Zeile Spalte: 124
| 89 Fehler: Ungültiger Wert "189px" im Attribut "height".
| Es sind nur ganze Zahlen oder prozentuale Angaben (z.B. 10%) erlaubt.
| Fehlerstelle:
|
| ...er_oben.jpg" width="400px" height="189px" alt="Lenkeransicht von vorne ob
|
|
|
| Spalte: 109
| Fehler: Ungültiger Wert "400px" im Attribut "width".
| Es sind nur ganze Zahlen oder prozentuale Angaben (z.B. 10%) erlaubt.
| Fehlerstelle:
|
| ...hotos/mini/lenker_oben.jpg" width="400px" height="189px" alt="Lenkeransic
`---------------------------------------------------------------------
Offensichtlich dürfen die Attribute "height" und "width" in einem img-Tag nur Zahlen oder Prozentwerte enthalten. Wobei reine Zahlen als Angaben in Pixeln verstanden werden. Die Angabe der Maßeinheit "px" ist aber offensichtlich nicht erlaubt.
Ich habe das mal in den Specs vom W3 nachgeschlagen. Diese bestätigen Validome. (Hier die Specs für HTML4.01, die für XHTML sind so unübersichtlich, entsprechen der Sache aber)
http://www.w3.org/TR/html401/struct/objects.html#edef-IMG
http://www.w3.org/TR/html401/sgml/dtd.html#Length
Wenn ich mir den Kommentar erlauben darf: Ich finde es ziemlich merkwürdig in einer technischen Spezifikation die Angabe von Maßeinheiten zu verbieten. Das sollte viel mehr vorgeschrieben sein. Na, was solls. Ich will die W3-Götter nicht verunglimpfen.
--
bis dann
Hello out there!
| 89 Fehler: Ungültiger Wert "189px" im Attribut "height".
| Es sind nur ganze Zahlen oder prozentuale Angaben (z.B. 10%) erlaubt.
| Fehlerstelle:
|
| ...er_oben.jpg" width="400px" height="189px" alt="Lenkeransicht von vorne ob
Ein gegen die DTD [XHTML1-DTD] validierendes Programm kann hier keinen Fehler melden, weil hier kein Fehler vorliegt:
<!ATTLIST img
%attrs;
src %URI; #REQUIRED
alt %Text; #REQUIRED
longdesc %URI; #IMPLIED
height %Length; #IMPLIED
width %Length; #IMPLIED
usemap %URI; #IMPLIED
ismap (ismap) #IMPLIED
>
Nachgeschaut, was sich hinter der Parameter-Entity 'Length' verbirgt:
<!ENTITY % Length "CDATA">
<!-- nn for pixels or nn% for percentage length -->
Beachte, dass die erklärende Zeile ein Kommentar ist, der für eine Maschine keinerlei Relevanz hat.
Mehr als den Datentypen 'CDATA' gibt eine DTD nicht her; es gibt keinen Datentypen 'Number'.
Anders in XML Schema, dort ist eine solche Einschränkung von Zeicheninhalt nur auf Zahlenwerte möglich.
Ich nehme an, dass Validome nicht gegen die DTD, sondern gegen das strengere XML Schema [XHTML1-SCHEMA] validiert.
Allerdings: “XHTML 1.0 in XML Schema
This document describes non-normative XML Schemas for XHTML 1.0.
These Schemas are still work in progress, and this document does not
change the normative definition of XHTML 1.0.” [HTML-HOME]
Offensichtlich dürfen die Attribute "height" und "width" in einem img-Tag nur Zahlen oder Prozentwerte enthalten. Wobei reine Zahlen als Angaben in Pixeln verstanden werden. Die Angabe der Maßeinheit "px" ist aber offensichtlich nicht erlaubt.
Sie kann per DTD nicht verboten werden. Allerdings ist sie ungültig.
Ich habe das mal in den Specs vom W3 nachgeschlagen. Diese bestätigen Validome.
Nein; s.o.
(Hier die Specs für HTML4.01, die für XHTML sind so unübersichtlich, entsprechen der Sache aber)
?? Ich finde XML wesentlich übersichtlicher als SGML.
http://www.w3.org/TR/html401/struct/objects.html#edef-IMG
http://www.w3.org/TR/html401/sgml/dtd.html#Length
Ich finde es ziemlich merkwürdig in einer technischen Spezifikation die Angabe von Maßeinheiten zu verbieten. Das sollte viel mehr vorgeschrieben sein.
In CSS ist sie das auch (außer beim Wert 0). Dass in HTML Pixelangaben ohne Einheit erfolgen, hat sicher historische Gründe.
Ich will die W3-Götter nicht verunglimpfen.
Bessr is’; Ketzer kommen auf den Scheiterhaufen.
See ya up the road,
Gunnar
Hallo,
Mehr als den Datentypen 'CDATA' gibt eine DTD nicht her; es gibt keinen Datentypen 'Number'.
» The HTML 4.01 specification includes additional
» syntactic constraints that cannot be expressed within
» the DTDs.
Quelle: http://www.w3.org/TR/1999/REC-html401-19991224/sgml/dtd.html
Verstehe ich richtig, dass die DTD-Syntax nicht mächtig genug ist um die Vorgaben des W3C maschinenlesbar auszudrücken. Oder ist es reine Schlamperei, dass ein Datentyp 'Number' nicht definiert wurde?
Anders in XML Schema, dort ist eine solche Einschränkung von Zeicheninhalt nur auf Zahlenwerte möglich.
XML Schema sind also mächtiger als die DTD-Syntax?
Ich habe das mal in den Specs vom W3 nachgeschlagen. Diese bestätigen Validome.
Nein; s.o.
Das verstehe ich nicht. Nur weil der W3-Validator auf Grund von DTDs und nicht wie Validome (scheinbar) auf Grund von XML Schema arbeitet, werden seine Ausgaben im Sinne der gesamten Spezifikation doch nicht richtiger?!
(Hier die Specs für HTML4.01, die für XHTML sind so unübersichtlich, entsprechen der Sache aber)
?? Ich finde XML wesentlich übersichtlicher als SGML.
Sind die DTDs in SGML geschrieben? DTD-Syntax=SGML??
Ich habe weder Ahnung von SGML noch von XML, aber in den DTDs finde ich mich ein wenig zurecht, im Gegensatz zu den XML Schema.
Grüße,
Jan
Hello out there!
Verstehe ich richtig, dass die DTD-Syntax nicht mächtig genug ist um die Vorgaben des W3C maschinenlesbar auszudrücken.
Ja. Siehe auch [XHTML1 §B, XHTML1 §4.9]
XML Schema sind also mächtiger als die DTD-Syntax?
„Die Schema-Sprache […] hat die Ausdrucksmöglichkeiten der XML 1.0 Dokumenttyp-Definitionen (DTDs) und erweitert diese beträchtlich.“ [XMLSCHEMA-1]
Das verstehe ich nicht. Nur weil der W3-Validator auf Grund von DTDs und nicht wie Validome (scheinbar) auf Grund von XML Schema arbeitet, werden seine Ausgaben im Sinne der gesamten Spezifikation doch nicht richtiger?!
Rein formal betrachtet doch. Wie gesagt, für XHTML 1.0 ist nicht das XML Schema normativ, sondern die DTD.
Dennoch ist das Verhalten des Validome durchaus sinnvoll. Bei 'width="42px"' bekommt man halt gesagt „hey, da stimmt was nicht“.
?? Ich finde XML wesentlich übersichtlicher als SGML.
Sind die DTDs in SGML geschrieben?
Die HTML-DTDs ja, die XHTML-DTDs sind in XML ...
aber in den DTDs finde ich mich ein wenig zurecht, im Gegensatz zu den XML Schema.
... und ich meinte den Unterschied zwischen HTML- und XHTML-DTDs; letzter finde ich übersichtlicher.
See ya up the road,
Gunnar
hallo,
Die HTML-DTDs ja, die XHTML-DTDs sind in XML ...
aber in den DTDs finde ich mich ein wenig zurecht, im Gegensatz zu den XML Schema.
... und ich meinte den Unterschied zwischen HTML- und XHTML-DTDs; letzter finde ich übersichtlicher.
Ah, der Wald lichtet sich und dem unerfahrenen User werden einige Dinge klarer. Ich bedanke mich!!
Grüße,
Jan
Hi,
Verstehe ich richtig, dass die DTD-Syntax nicht mächtig genug ist um die Vorgaben des W3C maschinenlesbar auszudrücken. Oder ist es reine Schlamperei, dass ein Datentyp 'Number' nicht definiert wurde?
Es gibt einen Datentyp NUMBER (wird z.B. für das tabindex-, maxlength-, rows-, cols- oder size-Attribut verwendet).
NUMBER erlaubt allerdings nur Ziffern.
Damit wären also keine Prozentwerte möglich, da das %-Zeichen keine Ziffer ist.
Man könnte argumentieren, daß NUMBER ja zusätzlich als letztes Zeichen auch noch das %-Zeichen erlauben könnte.
Aber dann wären auch bei tabindex, maxlength oder size Prozentwerte möglich. Wieviele Zeilen hat eine Textarea mit rows="42%"?
cu,
Andreas
Hallo Andreas, Jan,
Oder ist es reine Schlamperei, dass ein Datentyp 'Number' nicht definiert wurde?
Nein, hier kommt etwas anderes zum Vorschein: XML sollte einfacher als SGML sein. Deswegen haben sie diverses Zeugs rausgeschmissen. XML ist also eine Teilmenge von SGML.
Und so einfach ist ein Datentyp „Number“ ja nicht. Mal abgesehen von den mathematischen Möglichkeiten, Zahlen zu unterteilen (Ganze Zahlen, Rationale Zahlen, Irrationale Zahlen ...), gibt es haufenweise unterschiedliche Schreibweisen für diese Zahlen und sonstige Einschränkungen. Wirf mal ein Blick auf das Diagramm der eingebauten Datentypen von XML Schema. Du wirst dort auf einen Blick haufenweise Datentypen für Zahlen sehen. Aber alle werden textuell irgendwie ausgedrückt, damit es da nicht zu Verwechselungen kommt, braucht es Datentypen. Denn auf der Ebene, wie Attribute zu interpretieren sind, ist XML sehr textbasiert.
Es gibt einen Datentyp NUMBER (wird z.B. für das tabindex-, maxlength-, rows-, cols- oder size-Attribut verwendet).
NUMBER erlaubt allerdings nur Ziffern.
Der Datentyp NUMBER (und seine Verwandten NUMBERS, NUTOKEN und NUTOKENS) für Attributwerte existiert nur in SGML. In XML existiert der Datentyp nicht.
Also wurde bei der Umschreibung der SGML-DTD von HTML 4.01 in die XML-DTD von XHTML 1.0 Dinge wie dieses hier ...
~~~xml
<!ATTLIST A
-- ... --
tabindex NUMBER #IMPLIED -- position in tabbing order --
-- ... --
>
... durch so etwas ersetzt ...
~~~xml
<!ENTITY % focus
-- ... --
tabindex %Number; #IMPLIED
-- ... --
>
... wobei das Entity %Number so definiert ist ...
~~~xml
<!ENTITY % Number "CDATA">
<!-- one or more digits -->
... sprich, es hat nur noch den Datentyp CDATA, banal ausgedrückt "String". Die Beschränkung auf Ziffern steht zwar noch in einem Kommentar, kann aber nicht mehr durch die DTD ausgedrückt und gegen diese DTD validiert werden, da DTDs NUMBER nicht mehr kennen und damit auch nicht XML Prozessoren nicht mehr; es sei denn, man stolpert über einen SGML Prozessor.
Tim
hi,
| Fehler: Ungültiger Wert "189px" im Attribut "height".
| Es sind nur ganze Zahlen oder prozentuale Angaben (z.B. 10%) erlaubt.
| Fehlerstelle:
|
| ...er_oben.jpg" width="400px" height="189px" alt="Lenkeransicht von vorne obOffensichtlich dürfen die Attribute "height" und "width" in einem img-Tag nur Zahlen oder Prozentwerte enthalten. Wobei reine Zahlen als Angaben in Pixeln verstanden werden. Die Angabe der Maßeinheit "px" ist aber offensichtlich nicht erlaubt.
Laut HTML-Standard nicht.
Wenn ich mir den Kommentar erlauben darf: Ich finde es ziemlich merkwürdig in einer technischen Spezifikation die Angabe von Maßeinheiten zu verbieten.
Warum?
Es ist _definiert_, dass % Prozent bedeutet, und reiner Zahlwert Pixel.
http://www.w3.org/TR/1999/REC-html401-19991224/sgml/dtd.html#Length:
"nn for pixels or nn% for percentage length"
Allerdings ist der Inhaltstyp einer solchen Length CDATA, und daher lässt sich durch eine einfache DTD-Validierung ein solcher Fehler wie oben nicht feststellen.
Du könntest auch width="xyz" reinschreiben - bei einer Validierung gegen DTD fiele dies nicht auf. Bei einer Schema-Validierung sieht dies anders aus.
gruß,
wahsaga
Hallo,
... bei mir meckert validome aber an, dass in einer <textarea> keine Col und Row-Attribute gesetzt sind. Aber für den Style ist doch CSS verantwortlich!
Klar, ich habe jetzt in der XHTML-Strict-DTD nachgeschaut, das W3C sagt auch, dass die beiden Attribute erforderlich sind, aber wo ist da der Sinn?!
Grüße,
Willi
Klar, ich habe jetzt in der XHTML-Strict-DTD nachgeschaut, das W3C sagt auch, dass die beiden Attribute erforderlich sind, aber wo ist da der Sinn?!
Ich halte das für ein überbleibsel von früher. Denkbar wäre aber auch, dass die Angabe dazu da ist, Textbrowsern und anderen "minimalen" Browsern zu sagen, wie viel Platz freizuhalten ist.
Semantisch ist es auch soweit, dass durch die Angabe festgelegt wird für wieviel und damit auch grob für welchen Texttyp das Eingabefeld ausgelegt sein soll.
hi,
Klar, ich habe jetzt in der XHTML-Strict-DTD nachgeschaut, das W3C sagt auch, dass die beiden Attribute erforderlich sind, aber wo ist da der Sinn?!
Ich halte das für ein überbleibsel von früher. Denkbar wäre aber auch, dass die Angabe dazu da ist, Textbrowsern und anderen "minimalen" Browsern zu sagen, wie viel Platz freizuhalten ist.
Natürlich.
Eine Textarea ist wie ein Bild ein replaced inline Element.
Nur dass das Bild im Zweifelsfalle bei Fehlen sämtlicher Angaben zu den Ausmaßen seine Maße schlicht und einfach selber mitbringt - durch seinen Inhalt.
Textarea hat aber keine Möglichkeit, selber mitzuteilen, wie groß sie denn nun gedacht ist - ausser eben durch die Attribute rows und colls, die deshalb Pflicht sind.
gruß,
wahsaga
hi,
die Attribute rows und colls
-l
gruß,
wahsaga
Hallo,
Textarea hat aber keine Möglichkeit, selber mitzuteilen, wie groß sie denn nun gedacht ist - ausser eben durch die Attribute rows und colls, die deshalb Pflicht sind.
Die Angaben werden aber durch die CSS-Angaben width und height überschrieben, oder?
Grüße,
Willi
hi,
Textarea hat aber keine Möglichkeit, selber mitzuteilen, wie groß sie denn nun gedacht ist - ausser eben durch die Attribute rows und colls, die deshalb Pflicht sind.
Die Angaben werden aber durch die CSS-Angaben width und height überschrieben, oder?
Jein.
CSS überschreibt hier natürlich die Maße, die sich aus rows/cols in Verbindung mit der Schriftgröße implizit ergeben würden.
Die Attribute selber darf (und kann) es m.E. aber nicht überschreiben, deren Werte sind nach wie vor vorhanden.
Relevanz hätten die dann vielleicht noch, wenn man einen automatischen Umbruch am Zeilenende in den Daten, die die Textarea liefern soll, erzwingt (also explizites Einfügen eines \n in die Daten). Wie ein Browser dann sinnvoll reagieren soll, weiss ich auch nicht - nur x Zeichen in einer Zeile anzeigen, obwohl CSS-width die Textarea doppelt so breit macht?
gruß,
wahsaga
Hi,
Relevanz hätten die dann vielleicht noch, wenn man einen automatischen Umbruch am Zeilenende in den Daten, die die Textarea liefern soll, erzwingt (also explizites Einfügen eines \n in die Daten). Wie ein Browser dann sinnvoll reagieren soll, weiss ich auch nicht - nur x Zeichen in einer Zeile anzeigen, obwohl CSS-width die Textarea doppelt so breit macht?
? Natürlich. Aber das ist doch so selbstverständlich, daß ich mich frage: Bin ich noch nicht richtig wach, daß ich etwas mißverstehe? %-)
Gruß, Cybaer
Hi,
Die Angaben werden aber durch die CSS-Angaben width und height überschrieben, oder?
Ja. Alles was nach Layout in HTML aussieht, gilt mittlerweile als "CSS Level 0" und steht in der Kaskade (also der Priorität) unter jedem CSS.
Das macht es auch problemlos möglich, einem Dokument für Nicht-CSS-Browser ein "(HTML-)Layout" mitzugeben, und für CSS-Browser ein anderes ...
Gruß, Cybaer