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