Re: Versioning compatibility strategies and CSS as a positive role model

HI Henri,

Your message prompted me to add some CSS Material into the compatibility
strategies document.  Many members of the TAG, and frankly myself as well,
have wanted more treatment of CSS.  I believe all of your points have been
inserted, except for the point about deployment feature by feature which I
didn't think needed mention.  I will also bring up the point about the venn
diagrams.  I have regularly proposed them for the doc, and I did write up
some material on xml.com a while ago that showed them,
http://www.xml.com/pub/a/2006/12/20/a-theory-of-compatible-versions.html.  I
think myself and others are concerned about making the document any longer
than it currently is as we're trying very hard to get to closure.

Thanks again for the review.

Cheers,
Dave

On Sun, Sep 14, 2008 at 10:02 AM, Henri Sivonen <hsivonen@iki.fi> wrote:

>
> 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/
>
>
>
>