- From: liorean <liorean@f2o.org>
- Date: Fri, 31 Oct 2003 17:38:49 -0500 (EST)
- 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 UTC