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.
>
>
>