- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Sun, 14 Sep 2008 20:02:45 +0300
- To: www-tag@w3.org
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