- 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