Re: [CSS21] Versioning of CSS

On Thursday 07 July 2005 22:48, Karl Dubost wrote:
> Dear CSS WG,
>
> In the Abstract, I can read
>
> [[[
> CSS 2.1 is derived from and is intended to replace CSS2. Some parts
> of CSS2 are unchanged in CSS 2.1, some parts have been altered, and
> some parts removed. The removed portions may be used in a future CSS3
> specification. Implementations may refer to CSS2 for the definitions
> of features that have been removed, but for other features CSS 2.1 is
> the normative reference.
> ]]] - http://www.w3.org/TR/2005/WD-CSS21-20050613/#abstract
>
> There's no way in CSS to have a versioning information.
>
> The Conformance model of CSS was correct until a previous version of
> CSS was fully nested in the new version. So it was sure that all
> features of the previous version were included in the new version.
>
> The CSS WG intends to replace CSS 2.0 by CSS 2.1 and then change
>
>      - the properties acceptable in this generation of style sheets
>      - the behavior of some of these properties
>
> The CSS WG doesn't specify error handling, Cf
> http://www.w3.org/TR/2005/WD-CSS21-20050613/conform.html#q3
>
> It means for style sheets authors, that when CSS 2.1 is out, their
> style sheet becomes not correct with regards to the new version of
> the 2nd generation of CSS.
> It means that a user agent is unable to know which behavior is
> expected for the style sheet.
> It means that the expected behavior might change if implementations
> choose to implement CSS 2.1 instead of CSS 2.0
>
>
> This is a formal objection to CSS 2.1 without versioning information.

I think the versioning question has been beaten to death. Versions in 
document formats are undesirable in general. In particular, if there is 
a need for a new style sheet language, we will make one, but it won't 
be called "CSS version 2." That would be just confusing. It will be 
called KASWI or HAPA or TUBIU or something else that can't be confused 
with "CSS."

You (Karl) can read the minutes of the last CSS face-to-face meeting[1], 
where we tried to lists all the reasons why people asked for versioning 
information and found that they fall into two categories:

  1) To be sure that the style sheet works on a particular browser.

  2) To be sure that the style sheet conforms to a some policy, e.g.,
     company policy or school assignment.

In case 1, what you want is the version of the browser. What a browser 
supports has little to do with what the spec says, especially if the 
spec is a complex one. Often the browser makers themselves are not 
aware of all the things a browser does not support. Some bugs may not 
be discovered immediately. And for marketing reasons, they may not even 
want to tell you the bugs, even if they know them. That's why proposals 
such as "!required" or @feature won't work in practice.

In case 2, you are talking about how to tell a validator what profile to 
test against. One interesting idea is to express the policy (usually 
called "profile") in a machine-readable way: sort of like a DTD, but 
more detailed. That's too much work for now, but the W3C validator 
knows a number of predefined profiles. Hopefully it will be updated 
this summer to conform to the latest specs for those profiles.

In neither case do you need the name of the profile inside the file 
itself. It will be ignored anyway. The browser will handle what it can. 
It doesn't even know what it can't handle. The validator's task is to 
check everything in the file and to trust nothing; it will validate 
against whatever profile you give it out of band.

CSS is too big to develop in one go. Also, to get it accepted 10 years 
ago in the midst of the browser wars, it had to be very simple. That's 
why we have levels. But levels are just conceptual distinctions, meant 
for us, the developers. You can see them as profiles, if you wish, just 
like the mobile profile or the print profile, but in reality they 
aren't even that.

The fact that some features were previously thought to be in level 2 and 
are now reclassified as level 3 reflects their complexity, not their 
validity.


If you think it is useful to put the level of CSS inside the file, 
nothing stops you: /* This file is meant to use nothing outside of CSS 
level 2 */

We just haven't found any kind of software yet that needs such 
information.

And we don't want redundant information to be required. The smallest 
valid CSS file is an empty file. The smallest non-trivial one is only 
one line.

People have asked for all kinds of other metadata at the top of the file 
as well: author, copyright, date, version (of the file itself), editing 
history, language (of the comments), etc. If there is a need we can 
recommend some convention for it, for example XMP[2] or JavaDoc, but 
it'll be an orthogonal spec. No need to complicate the CSS spec with 
it.

[1] 
http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/att-0169/02-css-minutes.html#item17
[2] http://www.adobe.com/products/xmp/main.html



Bert
-- 
  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos                               W3C/ERCIM
  bert@w3.org                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France

Received on Monday, 11 July 2005 18:55:18 UTC