W3C home > Mailing lists > Public > www-style@w3.org > July 2005

Re: [CSS21] Versioning of CSS

From: Laurens Holst <lholst@students.cs.uu.nl>
Date: Mon, 11 Jul 2005 23:15:16 +0200
Message-ID: <42D2E164.3050004@students.cs.uu.nl>
To: Orion Adrian <orion.adrian@gmail.com>
Cc: www-style@w3.org

Orion Adrian wrote:

>There are already elements in CSS that I'd like to see go. They are in
>dispute and have been argued. And while my call for deprecation for
>specific elements hasn't succeeded here, there may be others where it
>should (at least in the future).
First of all, CSS can deal with such problems as they arise, why create 
such facilities now while they are not necessary? An @version "6.0" can 
be introduced anytime, and all versions without such a version can be 
considered "5 or lower".

Secondly, as Bert Bos said earlier in that message, changing one of the 
fundamental principles of CSS, which would warrant such versioning, will 
make it another language. So for changes on such a broad scale, let’s 
just not call it CSS anymore. For example, your proposal, it was another 
language too: something like XFrames.

Other changes can usually be dealt with by e.g. setting different modes 
(think: proposed box-model property), turning properties into shorthands 
(numerous occasions of this in CSS3), and finally, exactly *because* CSS 
has such a process of publishing working drafts and asking for input 
(which you so critisised) from both the public as the working group 
members with various industry experts from various companies, the CSS 
specifications are considered carefully and I think it is indeed 
possible to state that yes, every structure in CSS is optimal, and those 
which are not are not set in stone just because there is no versioning.

In a proprietary language’s process, as you vouched so much for, 
versioning might be necessary (I sure know it is necessary for my 
company’s product, we improve many things with every new version!), but 
for a language that has been developed in a standardizing process with 
such broad input, the need for that is much much less, and given some of 
the unique properties of CSS (cascading, strict error recovery rules), 
can be avoided at all.

You might think that different modes means that certain features can be 
deprecated, but the thing is: they have to be supported anyway! Existing 
CSS on the web won’t disappear for a long long time! Adding versioning 
will only mean that implementors have an additional complexity to deal 
with, disabling certain features/changing their behavior for different 
versions. As mentioned before that is horrible to create good tests for 
and to maintain properly. It will also complicate the story for people 
who want to incrementally upgrade their CSS with new features.

So, CSS is *by design* quite back- and forward-compatible, and there are 
plenty solutions when a problem arises (I mentioned two above, and many 
more creative ones can undoubtedly be devised). So if there is currently 
*no need* for versioning. Which brings us back to my first paragraph.


Ushiko-san! Kimi wa doushite, Ushiko-san!!
Laurens Holst, student, university of Utrecht, the Netherlands.
Website: www.grauw.nl. Backbase employee; www.backbase.com.
Received on Monday, 11 July 2005 21:15:18 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:19 UTC