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

On Tuesday 2013-05-14 19:54 -0400, Zack Weinberg wrote:
> 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.

One reason is that it would be very unexpected if switching a + to a
- changes whether something is valid.  I'd far rather have both be
an error than allow one and disallow the other.  (Switching a plus
to a minus is something I expect authors would expect to be able to
do without extensive testing.)

> ¹ read "I wouldn't have done it that way if I'd been there at the
> time": FUNCTION being one token, for instance.

The underlying difficult tokenization choice here is '-' being an
identifier character.

(Also, I should have mentioned in my previous message in this thread
that I'm looking at css-syntax as of hg revision
https://dvcs.w3.org/hg/csswg/rev/bb990ee9612e .)

-David

-- 
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                           http://www.mozilla.org/   𝄂