- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 29 May 2013 14:44:16 -0700
- To: Zack Weinberg <zackw@panix.com>
- Cc: "www-style@w3.org" <www-style@w3.org>
On Wed, May 29, 2013 at 2:32 PM, Zack Weinberg <zackw@panix.com> wrote: > 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. I think the correct decision is to not care in the slightest, and let whatever behavior falls out of the tokenizer just work. This is one of those things of so little importance that even the time you took to write the email is more than it deserves. ^_^ ~TJ
Received on Wednesday, 29 May 2013 21:45:08 UTC