Version information (was Re: HTML5 vs HTML6)

On Wednesday 2007-04-04 11:28 -0700, Chris Wilson wrote:
> Brad Fults <bfults@gmail.com> wrote:
> >That's actually an interesting question if one of the principles that
> >is going to be adhered to is lack of version syntax [1]. Should the
> >language specification itself have a version?

> >[1] - http://esw.w3.org/topic/HTML/ProposedDesignPrinciples#head-4a3dff6ff01c60eb72d8fa8ee1d0c2540e40ff8c

> I disagree with that proposed design principle.  Fundamentally, if
> you add features you are creating a new version.  Firefox 5.0 would
> implement a different "HTML" than Firefox 7.0.  It would be a
> mistake not to capture that in version identification.

It would be a mistake not to capture that in version identification
*if* the leading implementation were the definition of the standard.

If we add version information, it will be tempting for the
implementation that Web authors are most commonly "writing for" to
use the version information to keep improvements in standards
compliance from applying to existing pages on the Web (i.e., pages
marked as older versions).  It will do this to avoid breaking
content that works only in that one browser.  This means there will
be large numbers of commonly used pages on the Web that won't work
correctly with the latest standards implementation in the most
commonly used Web browser.

A situation like this will make it much harder for other browsers to
enter the market.  It will mean that, given linear growth in the
level of detail specified in standards (especially as standards
specify ambiguous cases to improve interoperability), the complexity
of implementations will grow quadratically.  To implement a Web
browser that is capable of browsing the Web, you will have to
implement not only what the standards say, but implement
reverse-engineered compatibility behavior corresponding to the most
commonly used older browser at the time each version was released.
(The situation becomes potentially even more difficult if there is
more than one browser at a time that authors are writing single
browser content for.  The smaller of them will have to choose
between maintaining compatibility with content written for it or
being compatible with the larger amount of content written for its
larger competitor.)  It will also encourage authors to write more
single-browser content because it will make it safer to do so, and
this will also discourage new entries in the browser market.

In other words, adding version information will make it harder for
competitors to enter the browser market and stay in the browser
market.  Competition is one of the key things that keep the Web
open.  Openness means (among other things) that anyone is free to
read/process the information on the Web.  This means that anyone is
free to improve the Web experience for users, which is what keeps
the Web thriving.  Placing substantial barriers of complexity in the
way of potential users may not make it impossible for new entrants
in the market, but it makes it substantially harder, and thus
substantially reduces the benefits of openness.

My initial phrasing of the "don't break the Web" principle [1] was
worded to limit itself to things that are interoperably implemented.
We should be willing (when provided good reasons to do so) to define
things that would require even the market leader to break
compatibility.  If we aren't, then we just become the committee to
propose new features to IE's developers and then re-document them
according to the bugs in IE's implementation.

But I think it should be one of the roles of this group to document
the behavior that is needed to be able to browse the Web, which
helps new browsers enter the market.  That means specifying things
to the level of detail that pages depend on, and it also means
compromising on the details where existing implementations disagree.

-David

[1] http://lists.w3.org/Archives/Public/public-html/2007JanMar/0412

-- 
L. David Baron                                <URL: http://dbaron.org/ >
           Technical Lead, Layout & CSS, Mozilla Corporation