RE: Versioning and HTML

On Mon, 27 Apr 2009, Chris Wilson wrote:
>
> I think we're talking at cross-purposes.  I am not, in this thread, 
> suggesting versioning in the language to solve any particular problem.  

Ah. My apologies. (I had assumed this was what you were suggesting because 
of the Subject line.)


> In fact, if you go back to my initial mail, I was 1) pointing out that 
> the CR stage won't resolve problems with defining behavior incorrectly 
> for the long term, or even necessarily being definitive enough in 
> behavior description,

Then what is the purpose of the CR stage? I thought the whole point of the 
CR stage was to check that the spec is in fact interoperably implementable 
(i.e. that it is definitive enough in behavior description), and to gain 
enough implementation experience to ensure that problems with defining 
behavior incorrectly for the long term are all caught.


> but 2) noting that a bigger, but related problem, is that vendors 
> shipping their implementations of in-progress specificiations, and then 
> using incompatibilities with shipped implementations as a reasoning for 
> not fixing their behavior, is a problem.

Feedback from vendors must be taken into account so that the spec is 
something they are willing to implement, sure. But I don't think this has 
caused any problems for people willing to put interoperability ahead of 
theoretical purity.


> I said that the only way out of this particular problem appears to be to 
> ask all vendors to prefix their non-CR'ed features, so that we don't 
> cycle around with this problem.

I think working closely with implementors to make sure they are aware of 
which cases should be prefixed, that they are aware of areas that are 
important to consider, and that they know which parts are likely to be 
stable and which are not, should be enough, if the browser vendors are 
willing to cooperate. It has, in fact, been enough for all but one of the 
browser vendors involved in HTML5's development. This doesn't require 
prefixing all non-CR'ed features.


> In this thread, I've been referring to problems INSIDE one version of 
> the spec (HTML in this case, presumable) - the language versioning need, 
> in my opinion, is for the deltas BETWEEN two major versions of the 
> language.

I think in practice languages evolve continually, and that the model of 
having different major versions (the way the W3C does) is the problem. 
Instead of releasing new major versions of HTML or CSS, it would be better 
if we had a continually evolving language definition where new features 
were slowly added in tandem with implementation work. In such a world, 
versioning wouldn't in fact make any sense.


> HTML5 defines it much more carefully, of course, but the supposition 
> that it will define everything, and define it correctly for the long 
> term, has always struck me as presumptuous at best.

I'm not really sure what you mean by "everything" and "correctly" here. 
The definition that matters is what deployed content depends on; the spec 
can only ever be an increasingly precise approximation of this.


> CSS2 defined behavior much more strictly than CSS1; that caused 
> incompatibilities.  CSS 2.1 redefined some behaviors from CSS2; that 
> caused incompatibilities too.

The key is that when defining behaviours of already-implemented features, 
we have to do it in a way that IS compatible with deployed content. This 
was not done with CSS 2.x.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 27 April 2009 21:57:54 UTC