Gurkenpapst
Mitglied
Registriert: 03.10.2007
Beiträge: 42
|
|
Unter http://www.webdevout.net/tidings/2008/06/22/dont-believe-everything-the-validator-tells-you/ gibt es ein paar Testcases, von denen in den ersten beiden auch Validome nicht alle Fehler erkennt.
Bei den seltsamen datapagesize- und event-Attributen frage ich mich, warum die nicht erkannt werden, die stehen doch nicht in der DTD? Beim type-Attribut im script-Element fehlt die Syntax-Prüfung, ein MIME-Type muss immer ein "/" enthalten.
Die mehrfachen, identischen name-Attribute in den a-Elementen sind ein klarer Verstoß,siehe http://www.w3.org/TR/html4/struct/links.html#h-12.2.1:
| Uniqueness: Anchor names must be unique within a document. Anchor names that differ only in case may not appear in the same document. |
Auch dürften bei a-Elementen in den name-Attribute keine Leerzeichen erlaubt sein, schließlich handelt es sich ja um den gleichen Namensraum. Da sollten dann ja die Regeln für das id-Attribut gelten. Hier ist die Spezifikation allerdings nicht ganz schlüssig, sie wäre dann nämlich unnötig lasch, weil sie für das name-Attribut CDATA erlaubt.
Ob der axis-Wert so zulässig ist, wage ich nicht zu beurteilen, die Spezifikation macht offenbar keine Angaben was dort für Werte gültig sind.
In der XHTML-Variante werden die geschachtelten form-Elemente nicht erkannt
|
|
| 08.07.2008 14:53:46 |
|
HTMELL
Administrator
Registriert: 11.05.2006
Beiträge: 620
|
|
Hi,
das "richt" nach viel Arbeit ;-)
Die Ankerfehler überraschen mich dann doch, das überprüfen wir bereits.
Ebenso überrascht mich der Fehler mit den geschachtelten form-Elementen, ist bestimmt wieder ein Fehler in den W3C-Schemata.
Momentan habe ich keine Zeit, aber in 1-2 Wochen knüpfe ich mir die Sachen mal vor.
_______________________________________
mfg
Thomas Mell
www.validome.org
|
|
| 08.07.2008 16:29:27 |
|
HTMELL
Administrator
Registriert: 11.05.2006
Beiträge: 620
|
|
Hi,
| Bei den seltsamen datapagesize- und event-Attributen frage ich mich, warum die nicht erkannt werden, die stehen doch nicht in der DTD? |
Doch, tun sie, auch wenn sie nicht in den Spezifikationen auftauchen - entspricht eben der gewohnte W3C-Qualtität.
Spec zum table-Element -> http://www.w3.org/TR/1999/REC-html401-1 ... edef-TABLE
Die dortige DTD:
Code:
<!ELEMENT TABLE - -
(CAPTION?, (COL*|COLGROUP*), THEAD?, TFOOT?, TBODY+)>
<!ATTLIST TABLE -- table element --
%attrs; -- %coreattrs, %i18n, %events --
summary %Text; #IMPLIED -- purpose/structure for speech output--
width %Length; #IMPLIED -- table width --
border %Pixels; #IMPLIED -- controls frame width around table --
frame %TFrame; #IMPLIED -- which parts of frame to render --
rules %TRules; #IMPLIED -- rulings between rows and cols --
cellspacing %Length; #IMPLIED -- spacing between cells --
cellpadding %Length; #IMPLIED -- spacing within cells --
> |
Und dann die "richtige" DTD:
Code:
<!ELEMENT TABLE - -
(CAPTION?, (COL*|COLGROUP*), THEAD?, TFOOT?, TBODY+)>
<!ATTLIST TABLE -- table element --
%attrs; -- %coreattrs, %i18n, %events --
summary %Text; #IMPLIED -- purpose/structure for speech output--
width %Length; #IMPLIED -- table width --
border %Pixels; #IMPLIED -- controls frame width around table --
frame %TFrame; #IMPLIED -- which parts of frame to render --
rules %TRules; #IMPLIED -- rulings between rows and cols --
cellspacing %Length; #IMPLIED -- spacing between cells --
cellpadding %Length; #IMPLIED -- spacing within cells --
%reserved; -- reserved for possible future use --
datapagesize CDATA #IMPLIED -- reserved for possible future use --
> |
Ähnlich sieht es beim script-Element aus: -> http://www.w3.org/TR/1999/REC-html401-1 ... def-SCRIPT
Code:
<!ELEMENT SCRIPT - - %Script; -- script statements -->
<!ATTLIST SCRIPT
charset %Charset; #IMPLIED -- char encoding of linked resource --
type %ContentType; #REQUIRED -- content type of script language --
src %URI; #IMPLIED -- URI for an external script --
defer (defer) #IMPLIED -- UA may defer execution of script --
> |
In der DTD dauchen sogar 2 Attribute aus dem nichts auf.
Code:
<!ELEMENT SCRIPT - - %Script; -- script statements -->
<!ATTLIST SCRIPT
charset %Charset; #IMPLIED -- char encoding of linked resource --
type %ContentType; #REQUIRED -- content type of script language --
src %URI; #IMPLIED -- URI for an external script --
defer (defer) #IMPLIED -- UA may defer execution of script --
event CDATA #IMPLIED -- reserved for possible future use --
for %URI; #IMPLIED -- reserved for possible future use --
> |
| Die mehrfachen, identischen name-Attribute in den a-Elementen sind ein klarer Verstoß... |
Das überprüfen wir schon sehr lange. Da aber die Werte der id- und name-Attribute unterschiedlich sind (diese müssen identisch sein) wird zunächst dieser Fehler bemängelt. Da nicht klar ist welcher den "richtige" Wert für die Dupplikatprüfung darstellt (beide Werte zu überprüfen macht keinen Sinn), werden diese Werte von der Prüfung ausgenommen.
| Auch dürften bei a-Elementen in den name-Attribute keine Leerzeichen erlaubt sein... |
Wie Du schon selber sagst "Hier ist die Spezifikation allerdings nicht ganz schlüssig", zumal dort NICHT die gleichen Regeln gelten wie bei den id-Attributen. Im name-Attribut dürfen Entities vorkommen, was in id-Attributen nicht erlaubt ist, siehe http://www.w3.org/TR/1999/REC-html401-1 ... l#h-12.2.3
| Because of its specification in the HTML DTD, the name attribute may contain character references. Thus, the value Dürst is a valid name attribute value, as is Dürst . The id attribute, on the other hand, may not contain character references. |
| Ob der axis-Wert so zulässig ist, wage ich nicht zu beurteilen, die Spezifikation macht offenbar keine Angaben was dort für Werte gültig sind. |
Tut sie doch?! http://www.w3.org/TR/1999/REC-html401-1 ... #adef-axis
| In der XHTML-Variante werden die geschachtelten form-Elemente nicht erkannt |
Im Gegensatz zum a-Element, bei welchem eine Schachtelung explizit untersagt ist (http://www.w3.org/TR/1999/REC-html401-1 ... l#h-12.2.2), ist dies beim form-Element nicht der Fall (http://www.w3.org/TR/1999/REC-html401-1 ... forms.html).
Da die DTD ein Teil der Spezifikation ist (wenn ich Dich zitieren darf ;-)), ist das Schachteln von form-Elementen erlaubt (sofern ein anderes Element dazwischen liegt).
Das macht zwar keinen logischen Sinn, aber das sind wir ja gewohnt ;-)
_______________________________________
mfg
Thomas Mell
www.validome.org
|
|
| 09.07.2008 21:48:44 |
|
Gurkenpapst
Mitglied
Registriert: 03.10.2007
Beiträge: 42
|
|
Danke für die Erklärungen.
Zu dem axis-Attribut: Du hast natürlich recht, dass dort CDATA-Werte gültig sind. Ich meinte allerdings die zulässigen Werte für die einzelnen Kategorienamen, die ja laut Spezifikation durch Kommas getrennt werden. Konkret für den Testcase interessant: Dürfen Whitespaces Teil eines Kategorienamens sein?
Zu der form-Schachtelung: In http://www.w3.org/TR/html4/intro/sgmltut.html#h-3.3.3.1 wird ganz am Ende des Abschnitts erwähnt
Similarly, the following element type declaration for FORM prohibits nested forms:
<!ELEMENT FORM - - (%block;|SCRIPT)+ -(FORM)> |
Sollte das -(FORM) also auch auf alle Nachfahrenelemente einen Einfluss haben? Oder ist mit nesting wirklich nur ein Kindelement gemeint. Sofern ich nichts übersehen habe, wird der Begriff nesting in der Spezifikation nirgends definiert. Mangels SGML-Spezifikation kann ich leider auch nicht auf anderem Weg feststellen, was nun korrekt ist.
|
|
| 11.07.2008 15:50:53 |
|
HTMELL
Administrator
Registriert: 11.05.2006
Beiträge: 620
|
|
Selbes Spiel beim a-Element
Code:
<!ELEMENT A - - (%inline;)* -(A) -- anchor --> |
Sofern mir bekannt, kann man in einer DTD nur unmittelbare Kindelemente verbieten, nicht in den gesammten Kindästen.
Deswegen überprüfen wir geschachtelte a-Elemente Heuristisch.
Es wäre kein Problem dies auch beim form-Element umzusetzen, allerdings fehlt dazu die Spezifikation die dies verlangt (s. o.).
_______________________________________
mfg
Thomas Mell
www.validome.org
|
|
| 11.07.2008 18:13:29 |
|
Wechsel zu
Die letzten Beiträge aus diesen Forum
|
|
