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

Re: [CSS21] Lack of version control for content

From: Christian Roth <roth@visualclick.de>
Date: Fri, 26 Aug 2005 00:25:22 +0200
To: "www-style Mailing List" <www-style@w3.org>
Message-Id: <20050825222522.1449@mail.visualclick.de>

Bjoern Hoehrmann wrote:

>  x { list-style-type: Hiragana; /* not in CSS 2.1 */
>      background-color: Menu;    /* deprecated in CSS 3.0 */
>      appearance: Menu;          /* only in CSS 3.0 */
>      color: Orange; }           /* not in CSS 2.0 */

This is the main reason (if not the only one) to come up with against
versioning: Getting the most from incomplete CSS implementations by
using CSS' cascading-/fallback-/error handling rules ("if you don't know
how to handle this property, then maybe try to use that - even if it's
from an older spec").

>With the scheme you are
>proposing you might have to split the style sheet into multiple or
>do something like
>
>  @version 2.0; 
>  x { list-style-type: Hiragana; }
>  @version 2.1;
>  x { background-color: Menu; }

I don't think this makes any sense; either it's a valid CSS X
stylesheet, or it isn't. If it is (supposed to be) valid, we only need
one declaration of version (like in XML, XSLT, ...). 

>Except that the Validator might not yet support CSS 3.0

I would not want it to use it in that case, anyway.

>The main problem is the default if no version is specified; 

This should be the combination of all CSS levels/versions ever being in
use. In other words, we would only check for validity concerning the
core grammar.

>There is consensus among http://www.w3.org/QA/Tools/qa-dev/ the few
>of us who, well, at least talked about it a few times that the many
>problems with the CSS Validator are best addressed by changing the
>system from validation via 1000+ Java files to a small schema-based
>validation system.

Wouldn't validation come almost for free using existing tools, if there
was a defined,  equivalent mapping from current syntax to XML-based
syntax for easier machine processing? Writing a translator from one
representation to the other and back (albeit possibly normalized) should
be possible quite easily using the core grammar of CSS (which is common
for all existing and future versions). Admittedly, I haven't done it so
far, and writing the Schema will be a tedious task for sure.

>It's highly likey that
>this "versioning" problem will be addressed with means to refer to
>such schema files instead of some version mark.

The only fear I have is that it will not change much for the situation:
Noone will stop you from modifying the Schema to your liking; so you
just reference your proprietary one  in your CSS, and we have the same
interoperability problems we have now when throwing this "valid" CSS at
some implementation.

Having standardized Schemas to be referenced, however, is nothing else
than having just a specific version declaration in the CSS (PUBLIC id in
DTD speak).

>In fact, even if the CSS Working Group introduces some @version rule
>like the one you are proposing, it's a bit unlikely that it'll be
>implemented any time soon, so it would not help the CSS Validator all
>that much.

I don't know why the W3C CSS Validator is referred to in discussions on
CSS at all. I think many have experienced its many bugs and weaknesses
(in many cases the implementations in actual browsers are correct when
the validator isn't), and everyone knows that it will not improve
anytime soon due to lack of resources. Making the current state of the
W3C CSS validator a guide for design decisions for the CSS language,
therefore, would be clearly wrong. I e.g. know of at least one other CSS
validator in  development that is mainly waiting for the core grammar of
CSS (tokenization, error handling) to become stable finally.
Implementing a profile selection based on an at-rule should be just an
issue of an hour.

One use case for versioning I have come up with is for the author to
declare which version/level of CSS he intends to write in his
stylesheet. When validating, he gets a warning when he has failed to so
so, or when throwing it at a UA, that one can issue a warning that this
version/level is not supported. Sure enough, this is not interesting to
end users, but only for authors, and probably not a vital feature, really...

Regards, Christian.
Received on Thursday, 25 August 2005 22:25:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:40 GMT