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

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