W3C home > Mailing lists > Public > www-style@w3.org > November 2003

Re: CSS version selectors?

From: liorean <liorean@f2o.org>
Date: Fri, 31 Oct 2003 17:38:49 -0500 (EST)
Message-ID: <3FA2E46A.5050708@f2o.org>
To: "www-style@w3.org" <www-style@w3.org>



Ian Hickson wrote:
> On Fri, 31 Oct 2003, David Hyatt wrote:
>>Never mind.  I misunderstood your test.  Yes, Safari fails that test,
>>but shouldn't it?  It seems like it should be forward-compatible and
>>not assume the whole rule is invalid.
> If you don't recognise anything in the selector, you should drop the whole
> selector.
> 
> This is because you don't know if later there will be an operator with a
> lower precedence than the comma operator.
> 
> For example:
> 
>    h1, h2 & div + *, p + *, ul + *, ol + * { ... }
> 
> ...where "&" is some new selector syntax that means "if one of the rules
> on the left hand side matched the element, and one of the rules on the
> right hand side matched the same element, apply these rules.
> 
> Now, that's a pretty useless selector extension, but the principle is that
> unless you know exactly what the selector means, you have no real
> knowledge of exactly how to parse it, and so shouldn't just assume it
> follows the same rules as normally.
> 
> An even less likely example would be:
> 
>    h1:fix, div ~ *, p ~ * { ... }
> 
> ...where ":fix" means "if you matched this selector, look at the other
> selectors and see if you match them too".
> 
> Now I'm not suggesting either of these extensions, but the forward
> compatibility parsing rules ensure that, if we (the current WG) or our
> successors decide to invent some wacky thing like this, parsers of today
> will happily ignore the whole thing instead of misparsing it.

As I understand it from the grammar of [CSS2.1] a ruleset contains one 
or more selectors, separated by comma, followed by an opening brace 
followed by one or more definitions, followed by a closing prace.

Each selector contains a simple selector, possibly followed by an 
arbitrary numer of other simple selectors separated by a combinator.

This means the comma is not part of the selector and is not a 
combinator, and you could as well separate something like this:
     selector1, selector2 { definition }
into
     selector1 { definition }
     selector2 { definition }
when you handle them. If one of those is not parsable, but the other is, 
wouldn't it be better to apply the one that is parsable?

(On the other hand, [CSS2.1:4.1.7] specifies that the entire ruleset 
should be dropped. But since the comma is not part of the selector, I 
fail to see why. something like your example could as well be expressed 
as h1:fix(div ~ *, p ~ *), only extending the selector instead of 
changing the grammar more profoundly, and that way the WG takes 
backwards compatibility into consideration.)

-- 
liorean <mailto:liorean@user.bip.net>

ViewStyles, ViewScripts, ToggleStyles and GraphicsInfo bookmarklets and 
Theme Switcher, Cookies Handler scripts:
<http://liorean.web-graphics.com/>
Received on Monday, 3 November 2003 10:03:58 GMT

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