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

Re: block-based parsing?

From: Orion Adrian <orion.adrian@gmail.com>
Date: Tue, 13 Sep 2005 10:03:09 -0400
Message-ID: <abd6c80105091307035e244b7b@mail.gmail.com>
To: www-style@w3.org

On 9/13/05, Dominique HazaŽl-Massieux <dom@w3.org> wrote:
> Hi,
> I know there has been some recent discussions on how and why CSS should
> have a versioning system [1], and I also understand that the CSS Working
> Group isn't keen into using versioning.
> While I mostly agree with the commenters about the usefulness of having
> versioning in the CSS style sheets, I'm wondering whether the group has
> considered an alternative solution (detailed below), which would not
> solve all the issues raised by the lack of versioning, but would at
> least help authors writing CSS across levels.
> Most of CSS techniques today deal with how using the various bugs in CSS
> parsers to get such or such a rule applied. I was wondering whether the
> idea behind that could actually be incorporated into the spec with an
> at-rule parsing command, ŗ la @mustUnderstand.
> Namely, such a rule would require a parser to skip the entire block
> contained into the @mustUnderstand scope if there is at least one rule
> it can't parse or containing a property it doesn't know.
> This would make it much easier to create style sheets that incorporate
> properties or syntax elements defined in later versions of CSS. It
> wouldn't solve all the problems, but would certainly help in many cases.
> Comments?

It's been suggested many times; it's been rejected many times.

To sum up the reasoning:

Browsers can't be trusted to accurately say what features they do and
don't support. So they may say they support a feature and go ahead
with the properties in the block, but it won't in reality support it
and you'll end up with a mess.

That about cover it everybody?


Orion Adrian
Received on Tuesday, 13 September 2005 14:03:20 UTC

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