W3C home > Mailing lists > Public > public-html@w3.org > June 2007

Re: Versioning re-visited (was : mixed signals on "Writing HTML documents", tutorial, etc.)

From: Ian Hickson <ian@hixie.ch>
Date: Thu, 21 Jun 2007 20:26:49 +0000 (UTC)
To: "Philip Taylor (Webmaster)" <P.Taylor@Rhul.Ac.Uk>
Cc: Philip & Le Khanh <Philip-and-LeKhanh@Royal-Tunbridge-Wells.Org>, www-archive@w3.org, HTML Working Group <public-html@w3.org>
Message-ID: <Pine.LNX.4.64.0706212013090.9149@dhalsim.dreamhost.com>

On Thu, 21 Jun 2007, Philip Taylor (Webmaster) wrote:
> >
> > The drawbacks, the cons, the problems caused by versioning, are:
> > 
> > * Authors will check their documents against obsolete versions of the 
> > spec (as, e.g., authors today check their documents against HTML4 
> > instead of HTML4.01), meaning that they do not benefit from the fixes 
> > that newer versions of the spec have received, and thus that their 
> > pages are not optimally conformant and accessible.
> 
> A document which was valid HTML 4.0 (and therefore, for example, did not 
> include the "name" attribute on an image) will still be valid today, and 
> an invalid HTML 4.0 document (which, for example, /did/ include such an 
> atribute) will still be invalid today.  That is indisputably correct.  

Well, no, it's not "indisputably" correct, since I am in fact disputing 
it. What possible help is it to the author to be still telling him that 
his <embed> element is non-conforming when the whole industry has moved on 
and now considers <embed> to be fine? What help is it to tell the author 
that his misguided (but previously compliant) use of the compact="" 
attribute on the <ul> element is still compliant, when almost no browser 
implements it and when it's been dropped from the specs?

Whether historical documents are compliant to their contemporary versions 
of the specs is of academic interest only. What matters is whether they 
are compliant _today_.


> > * An implementor may be tempted to implement a new rendering engine 
> > per version, leaving their old rendering engines with undocumented 
> > bugs, and forcing other implementors to implement a growing number of 
> > engines just to compete, eventually leading to the inability for other 
> > vendors to compete, and thus to the stagnation of the Web and its 
> > failure in the face of proprietary technologies (as, e.g., is already 
> > happening with IE8, and as has been experienced, in part, with "quirks 
> > mode").
> 
> There is no "forcing" here.

An artificial choice between being compatible with existing content on the 
one hand and losing market relevance on the other might not be "forcing" 
in the literal sense, but it is about as much of a choice as the choice 
not to break the law and face inprisonment.


> Leaving aside the marketing strength of Microsoft (which is /not/, IMHO, 
> this group's concern) [...]
> 
> I for one am not the least bit interested in helping to design a markup 
> language for those too lazy to think [...]

I don't know exactly who you think we _should_ be taking into 
consideration, but, in my opinion, the biggest browser vendor and the 
biggest population of Web designers are both very important concerns and 
we would be foolish to ignore them.


> > * The editors of future versions of the specification will be tempted 
> > to use versioning as a means to fix compatibility problems, instead of 
> > picking the harder, but ultimately better, option of addressing 
> > problems in the language itself (as, e.g., people have suggested 
> > several times already for HTML5).
> 
> I'm not sure which of those two options "people have suggested" (it's 
> not clear from your prose) but nor do I follow what you are saying : can 
> you give an example of "us[ing] versioning as a means to fix 
> compatibility problems" and compare/contrast this with the idea of 
> "addressing problems in the language itself" ?

For example, if we wanted to merge XForms with HTML5, we could do it by 
having a version switch which said that if the version number was HTML4 or 
earlier, you used the old-style Web Forms definition of <input>, and if 
the version number was HTML5 or above, you used the XForms definition.

The better (IMHO) solution is to just have one definition, and have it be 
compatible with the old-style Web Forms definitions, but add new features 
that provide what XForms provides.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 21 June 2007 20:29:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:01 GMT