Re: [CSS21] Versioning of CSS

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

3) Allow for deprecation or the obseleting of grammar elements,
properties or values.
 
I actually agree that one and two aren't good arguments for
versioning. However three is something that I've raised on this list,
but haven't felt was sufficiently delt with.

To not allow deprecation or for the obseleting of certain elements
(normal English usage) in the language feels to me that it is being
declared that every structure in CSS is optimal. Even if it could be
garunteed that everything that has been moved to REC status is
optimal, one cannot ensure that it will always be so. Some decisions
will be bad decisions. They will get to the REC stage; they will be
implemented and in some cases it will be bad. I need only point to
<i>, <b> and <font> in HTML to present cases where the ability to
obselete elements (HTML usage) and attributes has been invaluable.

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).


-- 

Orion Adrian

Received on Monday, 11 July 2005 19:18:44 UTC