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: Wed, 22 May 2013 09:32:01 -0700
Message-ID: <CAAWBYDC-JpA2OO6GcEh4Aqu9C8gwN_9FAyzrR=AZdEY+gW=bfw@mail.gmail.com>
To: "L. David Baron" <dbaron@dbaron.org>
Cc: Zack Weinberg <zackw@panix.com>, Simon Sapin <simon.sapin@exyr.org>, www-style list <www-style@w3.org>
On Fri, May 17, 2013 at 5:09 PM, L. David Baron <dbaron@dbaron.org> wrote:
> 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 .)

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?

Received on Wednesday, 22 May 2013 16:32:52 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:28 UTC