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

another an+b issue (was Re: [CSSWG] Minutes Telecon 2013-05-22)

From: Zack Weinberg <zackw@panix.com>
Date: Wed, 29 May 2013 17:32:29 -0400
Message-ID: <CAKCAbMhq=dwfUdWtyaYHdVjmVtWKXq1MTW6e=Sy4qdFVQ64fRw@mail.gmail.com>
To: "www-style@w3.org" <www-style@w3.org>
On Wed, May 29, 2013 at 4:43 PM, fantasai <fantasai.lists@inkedblade.net> wrote:
> an+b grammar
> ------------
> Scribe: fantasai
>
>   TabAtkins: an+b has always been defined handwavy, at best with completely
>              different tokenizer than CSS
>   TabAtkins: Had to retokenize or do some other magic
>   TabAtkins: In Syntax, defined it based on CSS tokens
>   TabAtkins: Change from Selectors 3 is that in case of "+n", can
>              have a space between sign and 'n'
...

Closely related issue that would be nice to resolve at the same time:
Whenever the stuff after the 'n' is being processed as an identifier
by initial tokenization, it may contain escaped characters, and in
particular, reanalysis as contemplated in Syntax 3 cannot distinguish

    :nth-child(3n-2)
    :nth-child(3n-\32 )

or

    :nth-child(n-1)
    :nth-child(n-\31)

Implementation convenience argues for accepting escaped digits in this
context, but consistency with the behavior when there's a space or
plus sign after the 'n' argues for rejecting them.

See Mozilla bug https://bugzilla.mozilla.org/show_bug.cgi?id=876585
for further discussion.  AFAICT the only situation where we can (as
specified) get different behavior due to escape sequences after the
minus sign is hexadecimal escapes for U+0030 through U+0039, but I
could have missed something.

zw
Received on Wednesday, 29 May 2013 21:32:56 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 29 May 2013 21:32:56 UTC