- From: Maciej Stachowiak <mjs@apple.com>
- Date: Tue, 23 Feb 2010 19:05:31 -0800
- To: Adam Barth <w3c@adambarth.com>
- Cc: HTML WG <public-html@w3.org>, Larry Masinter <masinter@adobe.com>
Thanks for the submission. I recorded this counter-proposal on the issue status list: http://dev.w3.org/html5/status/issue-status.html#ISSUE-004 On Feb 21, 2010, at 10:08 AM, Adam Barth wrote: > According to http://dev.w3.org/html5/status/issue-status.html, the > deadline has passed for Larry's initial change proposal for ISSUE-4. > The change proposal linked from that page is > http://lists.w3.org/Archives/Public/public-html/2010Jan/0015.html. > Here's my counter proposal: > > = Change Proposal for ISSUE-4: No DOCTYPE Versioning = > > == Summary == > > The DOCTYPE should not contain a version indicator. > > == Rationale == > > Historically, user agent implementors have invested a great deal of > effort to construct user agents that can process legacy HTML documents > properly. In particular, HTML5 contains algorithms painstakingly > researched to be compatible with exiting web documents. Current trends > indicate that future evolutions of the HTML language will continue to > be backwards compatible with the large number of existing HTML > document on the Web. For this reason, a version indicator is not > necessary at this time for HTML. > > Worse, a version indicator is actively harmful. Even though previous > versions of HTML have contained version indicators in the doctype, > these version indicators often bear little or no relation to the HTML > contained in the document. Authors simply copy-and-paste seemingly > meaningless boilerplate from one document to another. These version > indicators are simply ignored by user agents because processing the > version indicator has negative benefit to users. > > The doctype is used for one version-like purpose: selecting between > "quirks mode" and "standards mode" (well, and "almost standards > mode"). Supporting these different rendering modes in user agents adds > complexity, harming interoperability between user agents and making it > more difficult to author documents. The introduction of > X-UA-Compatible, a versioning-like mechanism, has received almost > universal distain from authors and made it nearly impossible to > predict how an HTML document will be rendered in a supporting user > agent. Adding hooks for more versioning serves only to facture the web > platform and retard the growth of the Web. > > The remainder of this section presents a point-by-point response to an > alternative change proposal for this issue: > http://lists.w3.org/Archives/Public/public-html/2010Jan/0015.html > > 1) Historical perspective on the doctype is laudable but independent > of whether HTML5 provides for a version indicator in the doctype. > 2) HTML5 alters the conformance status of a great many sequences of > bytes that might be presented with the text/html media type. It is > unclear why the conformance status of the doctype is of specific > concern. > 3) I agree that determining whether or not the doctype provides for > versioning is in scope for the working group. > 4) Supporting polyglot documents is independent of supporting > versioning. For example, the about:legacy-compat mechanism supports > XSLT generation of HTML documents without introducing a versioning > mechanism. > 5) I agree that other proposals for versioning HTML are also > undesirable. > 6) The rationale contained herein makes no reference to reverse > engineering costs. > 7) The doctype declaration /is/ mostly useless. Its sole use is to > select between quirks mode and standards mode, which is actively > harmful to authors of new HTML documents. > 8) The rationale contained herein makes no reference to version of > implementation. > 9) I agree that version-specific behavior by user agents is > undesirable. > 10) The syntax of the version indicator is not at issue in this > change proposal. > 11) Please see the detailed discussion below of the opportunity cost > of not including a version indicator. > 12) The syntax of the version indicator is not at issue in this > change proposal. > > == Opportunity Cost == > > This section is adapted from > http://lists.w3.org/Archives/Public/public-html/2010Jan/0295.html. > > The primary remaining rationale for having a version indicator is that > we might find such a version indicator useful in the future (even > though we agree that this eventuality is unlikely). Larry has written > that the opportunity cost of not making this change is merely a time > delay (i.e., between steps 1 and 2 described in > http://lists.w3.org/Archives/Public/public-html/2010Jan/0232.html) in > the hypothetical future in which we need to make an incompatible > change to HTML. Let's do a back of the envelope cost/benefit analysis > of this opportunity cost. > > First, we need to estimate various input quantities: > > 1) Probability that we'll make an incompatible change to HTML in the > future that necessitates these version markers. Larry and I agree that > this is unlikely. Let's say the probability is 1%. (I actually think > it's much lower, but a reasonable person might think that it's > higher.) > > 2) At what time in the future will this change be needed? Let's say 15 > years. Ian estimates that HTML5 will be a proposed recommendation in > 2022, so that gives us a couple years of headroom to realize that we > screwed up without being able to change the spec. > > 3) Delay between steps 1 and 2 caused by not changing the spec in this > way. Let's say it takes 5 years for people to update their validators > to understand that version indicators are ok. This seems ample to me. > (Notice that if people could update their validators instantly, there > would be no delay between steps 1 and 2 and the change to the spec > would have zero value.) > > 4) Long term, risk-free rate of return. We need this quantity to > estimate the time-value of various things. Five year treasuries are > trading at 2.62% when I wrote this analysis, but that's probably on > the lower side of historical averages. Let's say 5% as a more normal > discount factor. > > Ok, now we're ready do to do the calculation. Suppose the benefit is > $1,000,000. Deflating by the total probability of this eventuality > gives us $10,000. Now, we're only extracting the time value of this > benefit since we get the benefit, just five years later. That gives us > the utility lost due to delay of roughly $2126 = $10,000 - $10,000 / > (1.05)^5 (see http://en.wikipedia.org/wiki/Present_Value for an > explanation of this equation). Now, we need the present value of that > quantity, which is roughly $1027 = $2126 / (1.05)^15. > > In summary, for every million dollars of benefit we would get from > having this versioning feature, we only lose $1000 of utility today by > not making the change to the spec. That means the benefit of making > this change must be 1000x greater than the cost to have a positive > payoff. > > == Proposal Details == > > The proposal details herein take the form of a set of edit > instructions, specific enough that they can be applied without > ambiguity. > > * Perform no edits. > > == Impact == > > * Adopting this change proposal will have neither positive nor > negative effects because it does not propose modifying the current > specification. > * No conformance classes will change as a result of adopting this > change proposal. > * See the Opportunity Cost section of this change proposal for an > analysis of the risks involved in adopting this change proposal. >
Received on Wednesday, 24 February 2010 03:06:04 UTC