W3C home > Mailing lists > Public > public-html@w3.org > February 2009

RE: ISSUE-4: Versioning, namespace URIs and MIME types

From: Larry Masinter <masinter@adobe.com>
Date: Wed, 18 Feb 2009 13:42:53 -0800
To: Dan Connolly <connolly@w3.org>
CC: Ian Hickson <ian@hixie.ch>, HTML WG <public-html@w3.org>
Message-ID: <8B62A039C620904E92F1233570534C9B0118C86594C3@nambx04.corp.adobe.com>
I wrote:

> The need for multiple libraries comes from having incompatible
> languages or language versions. Incompatible languages and 
> language versions should be avoided--- however, not providing
> a way of detecting which of several incompatible languages
> or language versions was intended is a head-in-the-sand way
> of pretending like they don't exist, and makes the problem
> worse, not better.

To which Dan responded:
> I don't think so; the summary of this issue
>  http://www.w3.org/html/wg/tracker/issues/4
> shows that there are some eyes-open arguments
> that lead to the conclusion that we should not
> provide a way of detective which of several
> incompatible languages was intended:
> * L. David Baron "Version information" -
> http://lists.w3.org/Archives/Public/public-html/2007Apr/0279.html

But that argument is

> 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).

The temptation to "break the web" in the name of Browser Wars
exists whether or not the HTML specification provides a
documented versioning mechanism, and an argument of the form
"if we don't let them declare a version, then browsers that
only support one version won't exist" I think deserves being
called "head in the sand": not that those proposing the strategy
haven't thought about it, but rather that somehow a browser
vendor would be so influenced by not seeing a standard
versioning mechanism as to keep them from introducing a 
non-standard version mechanism (such as what we've already
seen with the various 'quirks' modes.)

Received on Wednesday, 18 February 2009 21:44:54 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:42 UTC