W3C home > Mailing lists > Public > public-html@w3.org > February 2010

Re: Updated DOCTYPE versioning change proposal (ISSUE-4)

From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 16 Feb 2010 19:41:07 -0800
Cc: Larry Masinter <masinter@adobe.com>, "public-html@w3.org" <public-html@w3.org>
Message-id: <2C5FA67A-41D5-4EE5-8433-72A426449BD2@apple.com>
To: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>

On Feb 16, 2010, at 7:27 PM, Leif Halvard Silli wrote:

> Maciej Stachowiak, Sun, 03 Jan 2010 19:45:13 -0800:
>>
>>> Documents served as an XML media type MAY include a DOCTYPE header,
>>> either to allow compatible content (so-called “polyglot” documents
>>> which are both valid HTML and also valid XHTML) or to support
>>> version-specific XML processing. While the DOCTYPE header is not
>>> required, including may help in XHTML/HTML crossover.
>>
>> Implementations MUST NOT use the DOCTYPE to trigger different
>> processing, but documents MAY use it to support version-specific
>> processing. Why would documents have a need to support
>> version-specific processing if version-specific processing is not
>> allowed?
>
> [Larry often changes subject when he replies, so sorry if I have
> overlooked his answer.]
>
> I think the answer to your question is that one may want to use a DTD
> based validator to check that one has coded a document according to a
> standard. For example, I may define a custom DOCTYPE which picks some
> bits from HTML5. Or use a HTML4 doctype, to which I add some elements
> or attributes from HTML5.

Should that be expressed by saying that validators (unlike other  
content consumers) may support version-specific processing, and that  
documents may only request version-specific processing from validators?

Also: should documents that request version-specific validation be  
considered conforming HTML5 documents? Even by validators that do not  
support version-specific processing?

>
> A Web browser should however not be allowed to support version
> specific  processing based on the version and feature info inside the
> DTD.
>
> But if HTML5 causes more DOCTYPE variants to cause quirks mode, then
> HTML5 has in practices introduced _negative_ version specific
> processing. QuirksMode becomes a punishment for not using the DOCTYPE
> variants that are currently mentioned in HTML5.

My understanding is that HTML5 tries to define, unify and limit the  
set of DOCTYPEs that trigger quirks mode. I don't believe anyone wants  
to see more doctypes trigger quirks mode.

REgards,
Maciej
Received on Wednesday, 17 February 2010 03:41:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:01 GMT