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

Ian Hickson wrote:
>>> So in conclusion, as I see it the arguments in favour of versioning 
>>> boil down to aesthetics, and the arguments against include dire things 
>>> like us losing competitiveness in the browser space. [2] [2] 
>> Actually, regarding "competitiveness in the browser space", I would like 
>> to point you again to the arguments from the Internet Explorer team:
> Given that the danger of versioning resulting in anti-competitive 
> behaviour was first brought up specifically because the IE team was 
> suggesting implementing a versioning feature that would have long-term 
> anti-competitive effects on the browser market, and that Microsoft is a 
> convicted monopoly-abuser in several jurisdictions and therefore has a 
> track record of taking advantage of features that can be leveraged against 
> healthy competition, I am not sure that appealing to Microsoft's position 
> is an effective counter-argument here.

Some people seem to think that the term "ad hominem " means mentioning 
something distasteful about the character of one of the participants 
during the course of a discussion whereas what it really means is an 
attempt to discredit an argument based on who made the argument.

The quoted paragraph above meets both criteria.  And doesn't further the 
goal of productive discussion.

  - - -

I happen to agree with Ian on the principle being discussed, but differ 
in how that principle should be applied here.

To make this point more clearly, I believe that any format or protocol 
designed for the internet should be designed to be "unversioned" and 
distributedly extensible.  This means no version attributes.  And also 
means that there is an architected means by which anybody for any 
purpose can add elements.

Yes, even Microsoft.  As the ACLU is fond of pointing out, defending the 
right of free speech is put to its severest test when the speaker is 
someone we disagree with most.

Applied here, this would mean that a "html5" format designed from 
scratch would provide a mechanism to incorporate even the likes of XFORMS.

What this means is that you put your faith in Darwinian forces.  The 
best way to prevent harmful forks is to provide a clear mechanism to 
enable them.

  - - -

But enough about philosophy.  If HTML5 were developed with a clean slate 
and had distributed extensibility, I would be with you on this argument. 
  But HTML5 doesn't have distributed extensibility, and it alternates is 
being positioned developed with a clean slate when that argument is 
convenient, and is positioned as being developed as an evolutionary 
follow-on to HTML4 when that argument is convenient.

And HTML4 was (unfortunately) defined as a versioned protocol, and the 
step from versioned to unversioned isn't exactly evolutionary.

  - - -

Yesterday, Thomas Broyer said something that clicked with me:

     If a future evolution of HTML needs to be incompatible with
     "HTML 5", it will "just" have to have another media type. This
     will ensure that "legacy UAs" won't fail at processing this
     eventual "new HTML".

The above should also be true if you s/5/4/.

Proposing a new MIME type for what is now called HTML5 would also 
surface the salient decision factors in this discussion -- after all, a 
new MIME type would please the clean slaters, the unversionists, and 
would even satisfy Microsoft's stated objection.  And those who wish to 
have evolutionary change won't even have to change one byte in their 

"application/html" may just fit this bill.

And those browser vendors that don't want to maintain two separate 
parsers (or alternately, have yet another set of mode flags) aren't 
really under any obligation to support HTML4 features like:


If such vendors chose to pipe "text/html" content through their newly 
created html5 parser, who among us will complain?

Of course, their ability to do that depends on the ability of this group 
to restrain itself from making changes that involve other than 
negligable breakage; but that's the case any without a new MIME type.

Furthermore, Microsoft could continue to process "text/html" as they do 
today for as long as they care to.  Heck, even products like Mozilla 
might benefit from being able to have a clear transition period of the 
duration that they can autonomously determine for themselves.

Now, tell me why that can't work, preferably without reference to my 
current employer.

- Sam Ruby

Received on Friday, 22 June 2007 15:09:46 UTC