- From: Yves Lafon <ylafon@w3.org>
- Date: Tue, 10 Feb 2009 09:37:18 -0500 (EST)
- To: Germain Garand <germain@ebooksfrance.org>
- cc: www-style@w3.org
On Tue, 10 Feb 2009, Germain Garand wrote: > Le mardi 10 février 2009, vous avez écrit : >> I completely agree that a grammar is not the place to enforce all the >> special cases of the specification, there are constraints that can't >> be expressed in the grammar, but in this specific case, I can't imagine a >> selector being a HASH and not a HASHIDENT (as specified by '#' IDENT ) >> >> If HASHIDENT is not needed, then IDENT is not needed, and we should move >> all the IDENT to NAME and put the constraint in the text of the spec :) >> Cheers, > > isn't the problem the other way around, that HASH is also used for tokenizing > of hexadecimal colors, which can't match IDENT? > > in KHTML, we resorted to contextual tokenizing to solve this ambiguity: > > #ff0000 { color: #00ff00; } > #00ff00 { color: #ff0000; } /* invalid selector */ > > I believe some engines are still affected by a side effect of this: Indeed the rule for color names should be changed to HASHIDENT|HASH, that is the only extra addition needed to make it work. hexcolor : [HASHIDENT|HASH] S* > <span style='color:#red'>Should not be red. Well, it seems more important to me to be able to filter bad selectors than bad syntax of a value, as checking the value requires specific checks difficult to capture in the grammar. like color: red is correct color: rouge is not (but both are 'ident' defining 'expr'), plus values may change between different CSS levels while the selector general syntax should stay the same. -- Baroula que barouleras, au tiéu toujou t'entourneras. ~~Yves
Received on Tuesday, 10 February 2009 14:37:27 UTC