- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 14 May 2013 16:26:32 -0700
- 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 correctly. 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. ~TJ
Received on Tuesday, 14 May 2013 23:27:19 UTC