Counter change-proposal for ISSUE-4 (html-versioning)

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 Sunday, 21 February 2010 18:09:05 UTC