Hi Julio!
I am working at Beorn Tech with Sébastien and Boubker.
Here is our analysis of the topic:
- In HTML4, the dtd reads:
<!--================ Document Head =======================================-->
<!-- %head.misc; defined earlier on as "SCRIPT|STYLE|META|LINK|OBJECT" -->
<!ENTITY % head.content "TITLE & BASE?">
<!ELEMENT HEAD O O (%head.content;) +(%head.misc;) -- document head -->
<!ATTLIST HEAD
%i18n; -- lang, dir --
profile %URI; #IMPLIED -- named dictionary of meta info --
>
<!-- The TITLE element is not considered part of the flow of text.
It should be displayed, for example as the page header or
window title. Exactly one title is required per document.
-->
<!ELEMENT TITLE - - (#PCDATA) -(%head.misc;) -- document title -->
which in clear text means that title (compulsory) and base (optional) may appear in head element in any order, as well as %head.misc (optional), without any particular ordering (no comma specified). I am not sure any ordering constraint may be inferred from the expression. I could not find any convincing clue in the sgml definition itself as how to interpret collocated groups without ordering operator. Did I miss something?
- In xHTML1, the dtd reads:
<!--================ Document Head =======================================-->
<!ENTITY % head.misc "(script|style|meta|link|object)*">
<!-- content model is %head.misc; combined with a single
title and an optional base element in any order -->
<!ELEMENT head (%head.misc;,
((title, %head.misc;, (base, %head.misc;)?) |
(base, %head.misc;, (title, %head.misc;))))>
which explicitly authorises meta elements before and/or after the title (and forces the title element to be present).
- In (x)HTML5, the order is up to the author. Additionally the new charset attribute is introduced to the meta element as an alias to <meta http-equiv="content-type" content="text/html; XXX">: <meta charset="XXX">. Refering to http://www.w3.org/TR/html5/semantics.html#charset, declaring utf-8 or iso-8859-1 should do whether before or after title (because both are ASCII-compatible).
In conclusion it seems the validator is not up to date with the standard as you and Jorge hinted.
The validators in use at our facility are validator.nu and W3C validator.
Sébastien, could you please check if the same behaviour affects W3C's validator?
Olivier
Please sign in to flag this as inappropriate.
