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

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

From: Zack Weinberg <zackw@panix.com>
Date: Tue, 14 May 2013 19:54:58 -0400
Message-ID: <CAKCAbMhbEH4mw5vZie9O3bAYTxbkVEp896W90OyexgzrvDjpcw@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Simon Sapin <simon.sapin@exyr.org>, www-style list <www-style@w3.org>
On Tue, May 14, 2013 at 7:26 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

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

I tend to agree -- this is the same situation as "a+++++b" in C, which
is a syntax error even though there is a possible tokenization that
makes it not a syntax error.  CSS has some unfortunate┬╣ tokenization
choices that make this more of a burden on the stylesheet author than
it might be, but it's not enough of a problem to bother with more than
"you need to put some whitespace there" informative notes.

zw

┬╣ read "I wouldn't have done it that way if I'd been there at the
time": FUNCTION being one token, for instance.
Received on Tuesday, 14 May 2013 23:55:21 UTC

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