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.

> <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.

Received on Tuesday, 10 February 2009 14:37:27 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 February 2015 12:34:23 UTC