W3C home > Mailing lists > Public > public-html@w3.org > December 2009

Re: DOCTYPE versioning change proposal (ISSUE-4)

From: Maciej Stachowiak <mjs@apple.com>
Date: Fri, 11 Dec 2009 23:26:06 -0800
Cc: "public-html@w3.org" <public-html@w3.org>
Message-id: <278E54B0-AB20-436D-B0EC-DB42CD3CDFBE@apple.com>
To: Larry Masinter <masinter@adobe.com>

On Dec 11, 2009, at 10:44 PM, Larry Masinter wrote:

> This email is to acknowledge your request for an updated change  
> proposal which includes a “better” rationale and which assembles the  
> pieces. I am willing to do that, but I’d like to address the  
> comments already received at the same time.

Addressing other comments at the same time is acceptable and indeed  
praiseworthy. Thanks for the acknowledgement.

Regards,
Maciej

>
> A simple rationale for the change proposal is that the DOCTYPE  
> declaration with a specification version actually is of some  
> (limited) utility.
>
> Comments that I think still need to be responded to are:
>
> To enhance the set of possible “Polyglot documents”, it seems useful  
> to make sure that the DOCTYPE declarations proposed are actually  
> compatible with XML. This may require either adding a SYSTEM  
> identifier or replacing the PUBLIC identifiers proposed with a  
> SYSTEM URI. This will require a change to the substance of the  
> proposal.
> If the text/html MIME type registration remains without reference to  
> previous HTML specifications, and there is a requirement that  
> updating a MIME type registration should not make previously valid  
> content invalid, then a fuller definition which allowed previously  
> allowed DOCTYPE declarations would be necessary.
> My survey  as to whether  “mostly useless” means the same thing as  
> “of limited utility” has been mixed: most say they are very  
> different, others say they could mean the same but have different  
> connotations or maturity levels.
> There was an argument that the change proposal would somehow “vastly  
> increased reverse-engineering costs” which doesn’t seem to me to  
> apply to what this proposal actually says, but since “vastly  
> increased reverse-engineering costs” has been used as a  
> justification for many of the decisions around the specification, it  
> seems worthwhile rebutting the argument more fully.
>
> I’d like to emphasize that the version indicator is not the version  
> of any implementation, but rather the version of the specification  
> for which the document (not any implementation) was intended to  
> follow, and to emphasize that version-specific browser behavior for  
> any of the now recommended version indicators is NOT allowed.   
> Clarifying this will help, I think, because most of the resistance  
> to version indicators in the past was due to the idea that a version  
> indicator was a trigger (NOT) or a version of an implementation  
> (NOT) or a version of a common pattern of usage (NOT) rather than a  
> version of a language specification.  I think this could be  
> corrected by only allowing DOCTYPE with version indicators to appear  
> in valid documents (well-formed, no error recovery allowed.)
>
>
> Larry
> --
> http://larry.masinter.net
>
> From: Maciej Stachowiak [mailto:mjs@apple.com]
> Sent: Tuesday, December 08, 2009 11:39 AM
> To: Larry Masinter
> Cc: public-html@w3.org
> Subject: Re: DOCTYPE versioning change proposal (ISSUE-4)
>
>
> Thanks for providing a Change Proposal for this issue! The chairs  
> are reviewing Change Proposals to ensure that they meet the required  
> structure. Here is our second round of feedback on this Change  
> Proposal:
>
> (1) The Rationale section does not appear to directly state  
> rationale. None of the sentences in the Rationale section give a  
> positive reason for adding versioning in general, or for putting it  
> in the doctype in particular. There is a citation of the issue and  
> general discussion, but a general citation of past discussion is not  
> sufficient. A Change Proposal must directly state a rationale itself.
>
> (2) It would be helpful to have all of the Change Proposal parts  
> collected in a single document, for benefit of Working Group members  
> reading it. Currently it is spread across three separate emails.
>
> We suggest updating the Change Proposal to reflect the feedback in  
> points (1) and (2).
>
> Regards,
> Maciej
>
>
> On Dec 1, 2009, at 4:20 PM, Larry Masinter wrote:
>
>
> Ø  It appears you are missing all the parts other than "Proposal  
> Details", most notably the rationale
>
> Sorry. Here they are:
>
>
> Summary: Describe the DOCTYPE attribute as previously used and give  
> advice for how it might continue to be used.
> Rationale: DOCTYPE has been part of HTML and is required. While it  
> has limited utility, it isn’t “mostly useless”. This proposal does  
> not add any new headers or elements to HTML, but shows the evolution  
> and reasons for no longer relying on DOCTYPE to affect browser  
> behavior.  For additional rationale and discussion, seethe HTML WG  
> tracker ISSUE-4:  http://www.w3.org/html/wg/tracker/issues/4
>
> Proposal Details: (as per previous email)
>
> Ø  you may want to rebut the following argument for why a version  
> attribute would be better than version information in the DTD: http://lists.w3.org/Archives/Public/public-html/2007Apr/1053.html
>
> My reading of that message is that you (Maciej) have an alternative  
> change proposal in mind; rather than using DOCTYPE (which  
> traditionally has been used in all previous versions of HTML), you  
> would like the working group to consider a different change  
> proposal, namely using a version attribute on the HTML element. I  
> think you’re free to submit your own change proposal if you wish, of  
> course, but I didn’t think a change proposal rationale needed to  
> rebut all previously discussed alternatives in order to be considered.
>
> But for what it is worth, to comment on your alternative proposal:
>
>     “easier to type correctly from memory”: If you’re relying on  
> memory, you should leave out the HTML version string, since it is  
> clearly not a “controlled environment”.
>   “easier to read”:  “ease of reading HTML markup directly” is not  
> particularly a design goal for HTML.
>
> Introducing a new versioning mechanism (an attribute on the html  
> element) would have the unfortunate consequence of introducing the  
> possibilities of inconsistencies, where the DOCTYPE contains one  
> version string and the version attribute contains another. HTML has  
> traditionally used DOCTYPE, the DOCTYPE is still used to introduce  
> ‘quirks’ mode, and what HTML has done in the past seems to me to be  
> more important than what other XML languages do (since HTML 5 is an  
> evolution of HTML 4 and not a new design from scratch.) If we’re  
> going to properly document all previous versions of HTML (as the re- 
> registration of text/html implies) then documenting previous values  
> of DOCTYPE and their effect, or at least alluding to that history,  
> seems to be called for.
>
> Larry
> --
> http://larry.masinter.net
>
> From: Maciej Stachowiak [mailto:mjs@apple.com]
> Sent: Tuesday, December 01, 2009 11:03 AM
> To: Larry Masinter
> Cc: public-html@w3.org
> Subject: Re: DOCTYPE versioning change proposal (ISSUE-4)
>
>
> On Dec 1, 2009, at 12:00 AM, Larry Masinter wrote:
>
>
>
> Here is a concrete change proposal for ISSUE-4.  This text replaces  
> section 9.1.1 (“The DOCTYPE”) in the current Editor’s draft.
> This issue has been discussed at length over several years.   I’ve  
> reviewed all the discussion I can find, and it seems like allowing a  
> evolving string would have some advantages for those that want one  
> without requiring a version string and disallowing any behavior  
> changes based on it.
>
> This Change Proposal is not well-formed. The list of what needs to  
> go in a Change Proposal is here:
>
> http://dev.w3.org/html5/decision-policy/decision-policy.html#change-proposal
>
> It appears you are missing all the parts other than "Proposal  
> Details", most notably the rationale. When you write the rationale  
> section, in addition to giving the reasons to have versioning, you  
> may want to rebut the following argument for why a version attribute  
> would be better than version information in the DTD: <http://lists.w3.org/Archives/Public/public-html/2007Apr/1053.html 
> >.
>
> Regards,
> Maciej
>
>
>
>
> Larry
> --
> http://larry.masinter.net
>
>
> 9.1.1 The DOCTYPE
>
>  A DOCTYPE is a header element with limited utility.  It was  
> inherited from the time when HTML was thought of as an application  
> of SGML. Previous versions of HTML mandated a DOCTYPE header with an  
> explicit reference to the version of the specification; for example,  
> see [HTML 4.01].
>
> Some widely-deployed web browsers will use a different rendering  
> mode if the DOCTYPE header is omitted and the document is being  
> served as “text/html” (and not as an XML media type.) For this  
> reason, DOCTYPE is still included in HTML, and (for content served  
> as text/html) is mandatory,  even when no specific version  
> identifier is supplied. Because this specification is intended to be  
> compatible with all previously deployed HTML content, and because  
> many hope that no incompatible changes will be ever be necessary in  
> any future edition or version of HTML, the DOCTYPE, while required,  
> is not used. Specifically:
>
> Except for explicitly defined previous versions of DOCTYPE strings  
> used to trigger “quirks mode” (see [#quirks-mode] and [hsvonin]),  
> implementations which consume HTML SHOULD NOT use the DOCTYPE to  
> trigger alternative behavior, as authors tend to use DOCTYPE  
> versions inconsistent with expected behavior.
> Implementations which validate HTML content SHOULD use the latest  
> version of this specification to validate against; validating only  
> against older specifications, or only against the indicated version,  
> is likely to be much lessuseful.
> Documents served as an XML media type MAY include a DOCTYPE header  
> to support enhanced workflow. Otherdocuments (not served as an XML  
> media type) SHOULD include a DOCTYPE header, since many browsers, in  
> the absence of a DOCTYPE header, will trigger a “quirks” mode of  
> rendering.
>
> The form of the doctype header is
>
>      <!DOCTYPE html>
> or <!DOCTYPE html PUBLIC “html version string”>
> or <!DOCTYPE html SYSTEM ”about:legacy-compat”>
>
> “html”, “PUBLIC” and “SYSTEM” are case insensitive, may have  
> additional spaces around them, and the html version string or the  
> “about:legacy-compat” string is wrapped  either with double or  
> single (apostrophe) quote marks. Note that XML allows many more  
> forms of DOCTYPE declarations which are not allowed. (The html  
> version string is defined below.)
>
> In most instances, the simple <!DOCTYPE html> form is all that is  
> required or recommended. The form with the “SYSTEM about:legacy- 
> compat” is provided to allow for those who oppose providing version  
> identifiers to still support processors that require a PUBLIC or  
> SYSTEM identifier.
>
> The form with a “html version string” SHOULD NOT be used unless the  
> content is served in a controlled environment where the intended  
> version is known.  The html version string is allowed primarily  
> because it may be useful for content management systems and other  
> development workflows  as a kind of metadata to indicate which  
> specification was being consulted when the HTML content was being  
> prepared.
>
> Using a html version string:
>
>  Until this specification is approved as a W3C recommendation,  
> documents MAY contain a DOCTYPE with an html version string that  
> identifying the specification referenced and its date.  The pattern  
> for the html version string is simple, andshould be clear from the  
> following examples:
>
>    <!DOCTYPE html PUBLIC “-//WHATWG//HTML 20100401">
>
> for the 2010 April 1 version of the WhatWG edition of the  
> specification.
>
>    <!DOCTYPE html PUBLIC “-//W3C HTMLWG//HTML 20100401">
>
> for the HTML working group editor’s draft of the same date.
>
>  If multiple alternative specifications are available in a  
> committee, the author’s nickname or handle may be used to  
> distinguish which draft is being referenced, e.g.,
>
>    <!DOCTYPE html PUBLIC “-//W3C HTMLWG hixie//HTML 20100401”>
> or
>    <!DOCTYPE html PUBLIC “-//W3C HTMLWG manu//HTML 20100401”>
>
> When this specification becomes a W3C Recommendation, a  DOCTYPE  
> with a correct html version string will be:
>
>    <!DOCTYPE html PUBLIC “-//W3C//HTML 5.0//EN”>
>
> However, HTML documents MUST NOT use the  “-//W3C//HTML 5.0//EN”  
> html version string until the edition of this specification  
> referenced is actually approved and published as a W3C Recommendation.
>
>
>
>
Received on Saturday, 12 December 2009 07:26:48 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:55 UTC