Datenschutzerklärung

Vorschlag: Hinweise und Warnungen einzeln auflisten.

Validome - Forum

Startseite Validome
RSS 2.0  
Sie sind nicht angemeldet. Atom 1.0  
Forum Home / Bug-Reports / Fehlermeldungen /

Vorschlag: Hinweise und Warnungen einzeln auflisten.

  Beitrag schreiben
Autor
Beitrag Seiten: 1
gurkenpapst
Gast



Neugierig auf die Änderungen in der neuen Version habe ich mal die Testseiten von Christoph Schneegans erneut validieren lassen. Bei http://schneegans.de/web/validome-bugs/http-meta-mismatch.aspx erscheint nun folgender Hinweis:


Die Zeichensatzkodierung im HTTP-Header (windows-1252) weicht von der Zeichensatzkodierung im Meta-Tag (iso-8859-1) ab.Dieses XHTML 1.0-Dokument wurde mit dem MIME-Type text/html ausgeliefert, was jedoch nur dann zugelassen ist wenn es den Richtlinien zu HTML entspricht.XML-Deklaration nicht vorhanden! Es wird ausdrücklich empfohlen eine XML-Deklaration dem Dokument hinzuzufügen.


Schön wäre es, wenn die drei Hinweise in einer Liste als einzelne Punkte erscheinen würden, so sisht man auf ersten Blick, dass es drei verschiedene Sachen sind. Zumindest fehlen Leerzeichen zwischen den Meldungen. ;)

Zu den einzelnen Punkten hätte ich ebenfalls noch Vorschläge:

Es wird zwar der Widerspruch der Zeichenkodierung (was macht das "satz" dort drin?) erkannt, nun wird aber gar nicht mehr erklärt, welche Angabe nun die höhere Gewichtung hat. Vor dem Update war das besser gelöst, auch wenn genau die falsche Angabe gewählt wurde. Oder macht Validome das immer noch und die ungenaue Meldung soll den Hinweis nur kaschieren? ;)

Es ist schön und richtig, auf die Problematik XHTML 1.0 mit den MIME-Typ text/html hinzuweisen. Es ist aber falsch, dass dies nur bei Beachtung der Richtlinien zur HTML-*Kompatiblität* in der *XHTML1-Spezifikation* (Richtlinien zu HTML sind für mich was anderes) zulässig ist. Es sind *Richtlinien*, sie werden vom W3C *empfohlen*, aber die Einhaltung von Richtlinien sind eben nicht zwingend erforderlich (allerdings dringendst anzuraten). Anhang C der Spezifikation ist eben nicht normativ. Generell kommt ein nicht XHTML-fähiger UA ja erstmal eh nicht mit so einem Dokument klar, dass es bei Berücksichtigung der Richtlinien fast überall dennoch klappt, liegt an der nicht vorhandenen Unterstützung von SHORTTAG. Dass die Empfehlung des W3C gegen die Auslieferung von XHTML1 als text/html nicht erwähnt wird, ist aus praktischen Grunden sicherlich richtig, das würde den Benutzer nur verwirren. application/xhtml+xml macht halt selbst in modernen Browsern noch einige Probleme, z.B. beim progresiven Seitenaufbau oder dem Abspeichern der Seite mit eingebetten Inhalten.

Bei der XML-Deklaration sollte man die Aussage nicht so pauschalisieren. Ein Hinweis auf den dadurch erzwungenen Quirksmode im IE wäre sicherlich sinnvoll. In der Praxis wird man die Deklaration daher (entgegen der Validome-Empfehlung) fast immer weglassen. Problematisch wird das Fehlen der Deklaration erst, wenn man eine andere Kodierung als UTF-8 oder UFT-16 nutzen möchte und gleichzeitig eine Kodierungsangebe im HTTP-Header nicht möglich ist bzw. das Dokument nicht zwingend über HTTP abgerufen wird. Daher sollte die Empfehlung nicht bei UTF-8/16-kodierten Dokumenten gar angezeigt werden, das Befolgen des Hinweises macht dort nur Probleme.


03.11.2005 01:21:39
  Zitieren
Validome
Administrator

Registriert: 04.04.2005
Beiträge: 313
@gurkenpapst

zu Punkt 1:


gurkenpapst schrieb:

Die Zeichensatzkodierung im HTTP-Header (windows-1252) weicht von der Zeichensatzkodierung im Meta-Tag (iso-8859-1) ab.Dieses XHTML 1.0-Dokument wurde mit dem MIME-Type text/html ausgeliefert, was jedoch nur dann zugelassen ist wenn es den Richtlinien zu HTML entspricht.XML-Deklaration nicht vorhanden! Es wird ausdrücklich empfohlen eine XML-Deklaration dem Dokument hinzuzufügen.


Ist jetzt - Deinem Vorschlag entsprechend - geändert. --> Hier zu sehen <--

zu Punkt 2


gurkenpapst schrieb:

Es wird zwar der Widerspruch der Zeichenkodierung (was macht das "satz" dort drin?) erkannt, nun wird aber gar nicht mehr erklärt, welche Angabe nun die höhere Gewichtung hat. Vor dem Update war das besser gelöst, auch wenn genau die falsche Angabe gewählt wurde.


Jetzt wird im Rahmen eines jeden Validierungsvorgangs die verwendete Zeichensatzkodierung und deren Quelle (z.B. HTTP-Header) - sofern ermittelbar - angezeigt.


gurkenpapst schrieb:

Oder macht Validome das immer noch und die ungenaue Meldung soll den Hinweis nur kaschieren? ;)


Das lässt sich für einen Papst doch recht eindeutig überprüfen: --> Hier <-- und --> da <--

zu Punkt 3


gurkenpapst schrieb:

Es ist schön und richtig, auf die Problematik XHTML 1.0 mit den MIME-Typ text/html hinzuweisen. Es ist aber falsch, dass dies nur bei Beachtung der Richtlinien zur HTML-*Kompatiblität* in der *XHTML1-Spezifikation* (Richtlinien zu HTML sind für mich was anderes) zulässig ist. Es sind *Richtlinien*, sie werden vom W3C *empfohlen*, aber die Einhaltung von Richtlinien sind eben nicht zwingend erforderlich (allerdings dringendst anzuraten). Anhang C der Spezifikation ist eben nicht normativ. Generell kommt ein nicht XHTML-fähiger UA ja erstmal eh nicht mit so einem Dokument klar, dass es bei Berücksichtigung der Richtlinien fast überall dennoch klappt, liegt an der nicht vorhandenen Unterstützung von SHORTTAG. Dass die Empfehlung des W3C gegen die Auslieferung von XHTML1 als text/html nicht erwähnt wird, ist aus praktischen Grunden sicherlich richtig, das würde den Benutzer nur verwirren. application/xhtml+xml macht halt selbst in modernen Browsern noch einige Probleme, z.B. beim progresiven Seitenaufbau oder dem Abspeichern der Seite mit eingebetten Inhalten.


Siehe ebenfalls diesen Validierungsvorgang, zweiter Hinweis.

zu Punkt 4


gurkenpapst schrieb:

Bei der XML-Deklaration sollte man die Aussage nicht so pauschalisieren. Ein Hinweis auf den dadurch erzwungenen Quirksmode im IE wäre sicherlich sinnvoll. In der Praxis wird man die Deklaration daher (entgegen der Validome-Empfehlung) fast immer weglassen. Problematisch wird das Fehlen der Deklaration erst, wenn man eine andere Kodierung als UTF-8 oder UFT-16 nutzen möchte und gleichzeitig eine Kodierungsangebe im HTTP-Header nicht möglich ist bzw. das Dokument nicht zwingend über HTTP abgerufen wird. Daher sollte die Empfehlung nicht bei UTF-8/16-kodierten Dokumenten gar angezeigt werden, das Befolgen des Hinweises macht dort nur Probleme.


Der betreffende Hinweis ist komplett entfernt worden.

Danke für die sinnvollen Vorschläge ! Noch ein kleiner Hinweis: hier gibt es nichts zu kaschieren, totzuschweigen oder gar Schönrednerei, Du bist hier schliesslich nicht beim W3C...;-)

Grüsse,
Yehuda


03.11.2005 18:27:30
  Zitieren
gurkenpapst
Gast



Hui, das ging aber schnell. Gefällt mir schon viel besser, allerdings störe ich mich immer noch an dem Wort Zeichensatzkodierung, das mir bisher noch nicht geläufig war. Ich wage nicht zu behaupten, dass meine Auffasung richtig ist, aber ich meine, es handelt sich hier um Angaben zur Zeichenkodierung. Ein und derselbe Zeichensatz kann prinzipiell sehr unterschiedliche Kodierungen nutzen, insofern bevorzuge ich das Wort Zeichenkodierung gegenüber dem häufiger anzutreffenden und meist synonym verwendeten Zeichensatz. Auch in http://www.w3.org/TR/html4/charset.html#h-5.1 wird zwischen character encoding und character set unterschieden, sofern man die beiden Terme wörtlich übersetzen darf, nutzt HTML als Zeichensatz sogar immer UCS.


Dieses XHTML 1.0-Dokument wurde mit dem MIME-Type text/html ausgeliefert, der jedoch nicht verwendet werden sollte, wenn das Dokument nicht den Richtlinien zur Kompatibilität mit HTML entspricht.

Kann man auch noch ohne die unschöne doppelte Negation schreiben: ... nur verwendet werden sollte ... Eventuell auch darauf hinweisen, dass dies von Validome (bisher) nicht geprüft wird. *Zaunpfahlwink*

Das völlige Entfernen des Hinweises zu der fehlenden XML-Deklaration halte ich für keine so gute Idee. In einem nicht-UFT-8/UTF-16-kodierten Dokument ist die Angabe ja sogar notwendig, wenn sie nicht über den Header gesendet wurde, UTF-16 ist dann auch nur mit BOM möglich. Ich wäre dafür, die Meldung wieder einzuführen, allerdings nur, wenn das Dokument nicht UTF-8-kodiert ist. Dann könnte man aber auf das Problem mit dem Quirks-Mode im IE hinweisen und eventuell vorschlagen UTF-8 als alternative Kodierung zu nutzen, wo man ohne Deklaration und ohne Quirksmode auskommt. Ich weiß allerdings nicht, inwieweit ihr hier auf spezielle Eigenarten der Browser hinweisen wollt. Da das Weglassen der Deklaration allerdings auch in den Empfehlungen zur HTML-Kompatiblität auftaucht, halte ich einen Hinweis darauf nicht unbedingt für verkehrt.

Eine weitere Meldung ist mir noch aufgefallen:

Dieses XHTML-Dokument wurde ohne Angabe einer Zeichensatzkodierung im HTTP-Header übertragen.
In diesen Fall müssen sowohl in der XML-Deklaration (z.B. <?xml version="1.0" encoding="ISO-8859-1"?>), als auch in einen Meta-Tag (z.B. <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">) eine Zeichensatzkodierung angegeben werden, wenn einer der Beiden vorhanden ist.
Bitte ergänzen Sie die Fehlenden Angaben im Dokument.


Hier sind gleich mehrere Sachen unstimmig:

Sie erscheint auch, wenn die Datei gar nicht per HTTP Abgerufen wurde, sondern über das Upload-Feld validiert wurde. Nur eine Kleinigkeit aber trotzdem zumindest verwirrend.

Es fehlt der Hinweis, dass beide Angaben gleich sein sollten, in der Meldung klingt es fast so, als wenn es eine beliebige sein kann. Das kann man problemlos in dem Satz unterbringen, anstatt "eine Zeichensatzkodierung" einfach "die verwendete Zeichenkodierung".

Es ist nicht zwingend so, dass ich beide angeben muss. In einem XHML-Dokument ist ohne jegliche Angabe die Kodierung UTF-8 (XML-Standardkodierung). Wenn ich das jetzt einem HTML-UA vorsetze, werde ich im meta-Tag UTF-8 angeben, da sonst die Kodierung für den undefiniert ist. Durch das Hinzufügen der XML-Deklaration handele ich mir hier wieder unnötig den Quirksmode im IE ein. Hier wieder mein Vorschlag: Keine Meldung bei UTF-8-Kodierungsangabe im meta-Tag, da hier die Deklaration unnötig wird. Ansonsten Hinweis auf Quirksmode/Kompatiblitätsrichtlinie und UTF-8 als Ausweg.

Schreibt man "Beiden" in diesem Fall nicht klein? Es bezieht sich ja auf die Angaben. Achtung: Halbwissen :) Das "Fehlenden" wird allerdings sicher klein geschrieben.

So, ich hoffe, ich habe nichts vergessen, das sollte erstmal alles sein.


04.11.2005 00:45:08
  Zitieren
Validome
Administrator

Registriert: 04.04.2005
Beiträge: 313
Hi Gurkenpapst,

Wir werden Deine Vorschläge überdenken und gegebenenfalls umsetzen. Es wird - bei einer eventuellen Umsetzung - aber einige Zeit dauern, wir haben in nächster Zeit beruflich alle Hände voll zu tun.

Grüsse,
Yehuda


04.11.2005 09:38:36
  Zitieren
Validome
Administrator

Registriert: 04.04.2005
Beiträge: 313
Hallo,

In einem nicht-UFT-8/UTF-16-kodierten Dokument ist die Angabe ja sogar notwendig, wenn sie nicht über den Header gesendet wurde, UTF-16 ist dann auch nur mit BOM möglich. Ich wäre dafür, die Meldung wieder einzuführen, allerdings nur, wenn das Dokument nicht UTF-8-kodiert ist.

Da fangen die Probleme an, woher soll Validome "wissen" daß das Dokument nicht in UTF-8 kodiert ist? Wenn der Header und die XML-Deklaration fehlt, verwenden wir UTF-8 (es sei denn BOM sagt etwas anderes). Ob das Dokument nun wirklich in UTF-8 und nicht z.B. in US-ASCII, ISO-xxx kodiert ist, können wir nicht feststellen da diese Bytegenau übereinstimmen könnten. Demnach können wir auch keinen Hinweis auf die (angeblich) fehlende XML-Deklaration ausgeben.


Es ist nicht zwingend so, dass ich beide angeben muss.

Es müssen beide angegeben werden wenn diese den Header "überstimmen" sollen, oder wenn der Header fehlt und einer der Beiden vorhanden ist.


Ich weiß allerdings nicht, inwieweit ihr hier auf spezielle Eigenarten der Browser hinweisen wollt.

Gar nicht, wir richten uns stur nach den Spezifikationen. Wenn eine Software mit den Standards Probleme hat, ist es nicht unsere Aufgabe darauf hinzuweisen.
Weiterhin müssten wir regelmäßig unsere Meldungstexte ändern wenn neue Browser erscheinen. Die ist in Hinsicht des Wartungsaufwandes (besonders bei 4 Sprachen) nicht vertretbar.

mfg
Thomas Mell


11.11.2005 16:11:34
  Zitieren
Seiten: 1   Beitrag schreiben
Wechsel zu

Die letzten Beiträge aus diesen Forum

Valid HTML 4.01