Re: [css-syntax] <an+b> grammar

Le 23/05/2013 00:32, Tab Atkins Jr. a écrit :
> The WG's preliminary conclusion is that consistency is good, so we
> should tweak the grammar to also allow whitespace in the "- n" case as
> well.  I can accept that (it's one more clause).  Thoughts?

If we allow whitespace between a sign and a bare "n", for consistency we 
should also allow whitespace between a sign and a signless A, which the 
grammar in the current ED does not seem to allow. For example:

- 2n
+ 3n+1


**Or,** just keep the Selectors 3 behavior and not allow whitespace 
between A (or n when A = ±1 is implied) and its sign. It is annoying to 
spec, but still doable. I still don’t see why this is a problem to begin 
with.

Le 15/05/2013 07:26, Tab Atkins Jr. a écrit :
> calc(), @supports, etc. only care about whitespace to force you into
> unambiguous situations in some cases.  There's not really a *reason*
> to force it - it's perfectly fine to just say that calc is "<number>
> <sign> <number>" or whatever, and then have a non-normative note that
> recommends whitespace around + and - signs to avoid them being eaten
> by the token on either side.  Same with @supports and avoiding
> "(foo)and(bar)" because it parses as an and() function - you should be
> able to say "(foo)and/**/(bar)" and have it work fine, as it tokenizes
> correctly.

Yes it *would* have been fine (that is, well-defined) that way, but 
that’s not what we resolved on. In both cases, the spec now requires an 
actual whitespace token.

My point is that because of calc(), an implementation already can not 
actively remove whitespace tokens early from declaration values. <an+b> 
as in Selectors 3 imposes no more whitespace-related constraints on 
implementations that calc() already does.


Cheers,
-- 
Simon Sapin

Received on Monday, 27 May 2013 11:21:59 UTC