Re: [CSS21] Lack of version control for content

* Chris Lilley wrote:
>This comment is sent from both the CDF WG and the SVG WG.

>Experience with the CSS validator shows that the lack of version
>identification is a significant problem for managing CSS content; there
>is no way to indicate to which of the multiple, changing, overlapping
>versions of CSS the stye sheet is attempting to comply. As the quoted
>section illustrates, there are incompatibilities between versions.

As one of the few people who have been involved with maintenance of
the CSS Validator, I don't think that's what experience shows. The
CSS Validator, or any such service for that matter, basically de-
termines applicable constraints, evaluates data objects against the
constraints and presents its observations in some way to the user.

The first and last parts are the most difficult ones. Currently the
first problem is solved by allowing the user to select a version or
if he does not do that, by assuming a default. If the default does
not work well, there is a problem. If the version selection does
not work well either, there is another problem. And if we change
the default, there is a third problem.

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

It would be highly undesirable to require the author to change the
style sheet just to please some Validator. 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; }
  @version 3.0;
  x { appearance: Menu; }
  @version 2.1;
  x { color: Orange; }

just to please the Validator. You can of course simplify this a
bit,

  @version 2.0;
  x { background-color: Menu; }
  @version 3.0;
  x { list-style-type: Hiragana; }
  x { appearance: Menu; }
  x { color: Orange; }

Except that the Validator might not yet support CSS 3.0 or might not
support the relevant CSS 3.0 module or the module might not be a CR
yet. So you'd probably need something more complex,

  @version 2.0,2.1,3.0;
  x { list-style-type: Hiragana;
      background-color: Menu;   
      appearance: Menu;         
      color: Orange; }          

Hmm, except that now the Validator would not know whether it should
complain about the system color or not. You would have similar
problems with media types; say, you want to check the style sheet
for conformance with both the Mobile and the Print profile.

Here is another problem:

  <html xmlns=...>
  ...
  <style ...>
    a {color:blue;fill:currentColor;background:white;font-size:12}
  </style>
  ...
  <p style='image-rendering:optimizeSpeed'>...
  <svg xmlns=...>
    <a style='white-space:normal' ...>
  ...

And http://www.w3.org/StyleSheets/Mail/message is a third one. And
these problems aren't really solved even by complex versioning
schemes, which is bad considering that "versioning" is not cheap,
even if you are really just asking for a @validate-as rule.

The main problem is the default if no version is specified; as the
ecosystem grows and evolves, picking the right one will become more
and more difficult. That's true for all formats, SVG 1.2 for example
proposes that indicating the version is made optional and there is
some strangeness that <svg version="1.1" ...> is legal SVG Tiny 1.2;
that's indeed highly problematic for the Markup Validator, I've
raised my concerns about it...

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.

There have been a few proposals for CSS Schema languages, e.g.
Microsoft Visual Studio.NET has such a system for the built-in CSS
Editor / Validator and my own draft language. It's highly likey that
this "versioning" problem will be addressed with means to refer to
such schema files instead of some version mark.

We don't know yet how it will look like, so we can't really request
anything from the CSS Working Group to support this at this point.
Once we know though I am sure the QA Dev group will communicate any
need to the CSS WG.

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. The CDF and SVG WGs are of course most welcome to discuss
any concerns about CSS Validation with the QA Dev group on the public-
qa-dev mailing list or http://esw.w3.org/topic/QaDev one of our
meetings. Even more so for discussion about the Markup Validator.

We might have missed something in the qa-dev discussions though, so if
the above does not really address your concerns, it would be helpful
if you could elaborate on the requirements for "version control" in
CSS and how the solution would deal with the cited problems.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Thursday, 25 August 2005 19:04:29 UTC