W3C home > Mailing lists > Public > www-style@w3.org > February 2009

Re: Issue in CSS21 grammar?

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
Message-ID: <Pine.LNX.4.64.0902100927330.1737@ubzre.j3.bet>

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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:16 GMT