RE: DOCTYPE versioning change proposal (ISSUE-4)

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.

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