W3C home > Mailing lists > Public > www-style@w3.org > May 2013

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 14 May 2013 16:26:32 -0700
Message-ID: <CAAWBYDCFjCtH8xDqRDB+QzK5b5eSdywx=ZD=FKG4ZFpUBuM20g@mail.gmail.com>
To: Simon Sapin <simon.sapin@exyr.org>
Cc: www-style list <www-style@w3.org>
On Tue, May 14, 2013 at 3:12 PM, Simon Sapin <simon.sapin@exyr.org> wrote:
> "Tab Atkins Jr." <jackalmage@gmail.com> a écrit :
>> I'll note, though, that this is now technically *slightly* more
> permissive than the original grammar: if you use any of the "+n" forms, whitespace is now allowed between the "+" and the "n", while it
> was illegal originally.  I couldn't wipe that out without abandoning property grammar entirely, since property grammar is entirely agnostic
> to whitespace between tokens.
> Why? Can't we have property-like grammars that are not agnostic to white space? It seems to me that we're gonna need this for calc(), @supports and Selectors at least.

No, we can't - you'd have to express it in prose.

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

Selectors does indeed need to be explicit about whitespace, but that's
fine - Selectors is special, and is okay to specify in terms of raw
tokens, as it currently is.

Received on Tuesday, 14 May 2013 23:27:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:30 UTC