- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 31 Oct 2003 22:04:43 +0000 (UTC)
- To: David Hyatt <hyatt@apple.com>
- Cc: "www-style@w3.org" <www-style@w3.org>, daniel@glazman.org, James Craig <work@cookiecrook.com>
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. -- Ian Hickson )\._.,--....,'``. fL U+1047E /, _.. \ _\ ;`._ ,. http://index.hixie.ch/ `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 31 October 2003 17:04:46 UTC