[Bug 20993] To facilitate migration, <!DOCTYPE html> should be recommended for the XHTML5 syntax.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=20993

--- Comment #5 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> ---
In reply to comment #4 from David Carlisle:

>> 1. The name part MUST be an ASCII case-insensitive match for the
>>    string 'html'.
> 
> There is a pre-existing requirement from XML 

As I think you said elsewhere, you are right that this bug first insisted on a
DTD-valid DOCTYPE, but that I now have switched to what we could call a
HTML5-valid approach. The reason can be summed up like so: While the old
validator performs a DTD-validity check of the DOCTYPE declaration (see
http://tinyurl.com/oldvalidator ), the NU validator explicitly skips the DTD,
and thus as well “blesses” whatever DOCTYPE name you might pick (see
http://tinyurl.com/newvalidator ). If you can convince the NU devs to perform
DTD check, then fine. 

>> 2. It is OPTIONAL whether there is a DTD associated with the
>>    DOCTYPE.
> 
> OK although saying that or not saying that adds nothing.

The spec says that XHTML5 documents are *permitted* to do <meta
charset="UTF-8"/>. The spec does not have to permit something  that is useless.
But the DOCTYPE rules that I propose here, can be defended from the same
motivation per which the spec allows <meta charset="UTF-8"/>.

>> 3. When there is no associated DTD, the DOCTYPE MUST match
>>    the DOCTYPE of the HTML syntax.
> 
> I think here you mean <!DOCTYPE html>

Yes. Or the legacy variant - <!DOCTYPE html SYSTEM "about:legacy-compat">.
(perhaps my text is unclear?)

>  but as for (1) this would be better
> phrased by saying that the document element MUST be html (but I'm not 
> sure we
> want to say that, it isn't a strictly necessary requirement)

I don't want to to say anything about prefixed XHTML - the NU validators allows
that. Fine. But it is true that these rules would not permit a DTD for a
prefixed XHTML. That said, it would be OK too me if the validator ignores the
DOCTYPE declaration for prefixed XHTML.

>> NOTE: A DOCTYPE declaration without an associated DTD does not
>>       have any effect on XML parsers and is only allowed in order
>>       to facilitate migration to and from HTML.
> 
> It could have some effect, in particular if the specified name is missing
> or mal formed it is a fatal parse error.

A DOCTYPE declaration without a name part does, I think, not qualify as a
DOCTYPE declaration, per XML 1.0.

>> 4. The associated DTD, if any, MUST define this specification’s
>>    list of named character references. Other character references
>>    MUST NOT be defined.
> 
> That requirement is incompatible with all the DTD currently listed in the
> HTML spec.

I specifically chose the wording 'associated' so that one can associate a
correct DTD with it. (As you know, the currently listed DTS will be parsed by a
conforming XHTML5 parser as if they do have the correct character references
defined.) If you have any idea about how this could be said better, then feel
free.

>> NOTE: Thus there is no requirement that the DTD is a complete <a
>>       href="http://www.w3.org/TR/xml/#dt-markupdecl">markup 
>>       declaration</a> that defines other aspecs of the language
>>       than the character references.
>> </INS>
> 
> 
> In your original comment you say
> 
> (yes, it could be <h:html xmlns:h="http://www.w3.org/1999/xhtml">, but in a
> XHTML document, the root has to be the 'html' element!
> 
> 
> But I don't see why that should be the case
> <!DOCTYPE h:html>
> <h:html xmlns:h=....
> 
> is valid xhtml 1.1 and works in common browsers, why say the root has to be
> html>
>
> The xhtml 1 dtd goes to extraordinary lengths to parametrise every 
> element name precisely so that this prefixed usage is allowed.

In the first text proposal I wrote (but not sent to this bug) I wrote up rules
which would have allowed a prefixed doctype. As told above, we could limit the
above rules to unprefixed XHTML ... (Especially) if that would make you more in
favor of what I propose in this bug, then I can add it ...

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 21 February 2013 13:20:34 UTC