Versioning compatibility strategies and CSS as a positive role model

Commenting on
http://www.w3.org/2001/tag/doc/versioning-compatibility-strategies-20080912.html

I think it's good to write down formal definitions of backwards and  
forwards compatibility. However, I think David Orchard's presentation  
at XTech 2008 communicated the points expressed in terms of set theory  
more effectively than the draft TAG finding. I think the Venn diagrams  
from the presentation slides could be good in the TAG finding as well.

I'm a bit disappointed to see that the draft finding mentions CSS only  
in passing as an example of a class of languages. I think  CSS is the  
greatest backwards and forwards compatibility success story of the  
W3C. I think it would be beneficial to analyze CSS as a positive role  
model in the context of backwards and forwards compatibility and  
language evolution.

CSS doesn't have versions but levels. More importantly, it has no  
syntax for denoting a level or a version. Instead, it has a well- 
defined processing model that covers safe ignoring of properties from  
the future and, on the other hand, the working group responsible for  
evolving the language can be trusted to evolve the language  
responsibly without breaking existing deployments. Moreover, the  
language doesn't get deployed in monolithic levels. Instead, the  
language gets deployed feature-by-feature, so the compatibility  
mechanism is constantly at work reconciling the different levels of  
support in different implementations and in different releases of a  
given implementation codebase.

It seems that successful browser-consumed Web languages in practice  
need to be evolved like CSS.

I think there are four things to note here:

  1) Not having version syntax works extremely well.

  2) Not having version syntax makes the people in charge of the  
language take backwards-compatibility seriously when they can't take  
the easy way out and introduce incompatible changes using a new  
version identifier as an excuse.

  3) It's important to remain compatible with the deployed language-- 
not with the previous specification.

  4) The compatibility characteristics don't need to just work between  
major spec iterations. Instead, they need to work with multiple  
implementations implementing different parts of the language at  
different levels at a given moment. The accept sets and defined sets  
of the language as snapshot in implementations is more important than  
the accept sets and defined sets as snapshot in RECs.

Further, CSS has a successful mechanism for experimentation in the  
form of vendor prefixes. This characteristic is enabled by the  
optional nature of presentation hints and by the egalitarian standing  
between CSS properties; there isn't a property that is above others  
like in markup the tag name has a special place compared to  
attributes. You can write stuff like
foo {
	white-space: pre;
	white-space: -pre-wrap;
	white-space: -o-pre-wrap;
	white-space: -moz-pre-wrap;
	white-space: -hp-pre-wrap;
	white-space: pre-wrap;
	word-wrap: break-word;
	-moz-border-radius: 1em;
	-webkit-border-radius: 1 em;
	border-radius: 1em;
}

In markup, you make an element have the name -webkit-canvas, -moz- 
canvas, -o-canvas and canvas at the same time--this could have been  
different if the generic identifier in SGML had been just another  
boolean attribute so that <foo> would be just shorthand for <foo="">.

P.S. The URI without the '.html' extension
http://www.w3.org/2001/tag/doc/versioning-compatibility-strategies
content negotiates between HTML and an XML vocabulary whose semantics  
aren't known to general Web clients, and the latter version is sent to  
Firefox 2. (Firefox 3 gets the HTML version.)
-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Sunday, 14 September 2008 17:03:28 UTC