Re: [css3-syntax] Added an "an+b parsing" section, please review

Le 01/02/2013 03:30, Tab Atkins Jr. a écrit :
> I added a small algorithm for parsing an+b values at
> <http://dev.w3.org/csswg/css3-syntax/#parse-anb-notation>.  It's just
> a "turn everything back into a string and reparse" algorithm.
>
> Does it look good?  Alternately, I could do it by looking at the
> original tokens, it's just a bit messier that way.  There's 6
> different ways a valid an+b can be tokenized, and one of them involves
> a dimension token with a unit matching /n[+-]\d+/.

It’s very good to have this in Syntax. Thanks!

"Turn tokens back to a string and reparse" is not pretty, but as you say 
parsing from tokens is worse. And more likely to have some corner cases 
wrong.


Is the an+b notation used in anything other than :nth-child() and 
related Selectors?

The various algorithms in §6. Parser Entry Points are assumed to parse 
from text. But for Selectors at least, an+b is in the arguments of an 
already-tokenized function so the input is a list of component values, 
not text. Although that does not make much difference as all the 
relevant tokens are preserved.


On to the algorithm itself:

Dimension tokens should also append their unit to the string. The 
"representation" is only that of the numeric part.


All whitespace tokens are ignored. This is not the case in the "nth" 
grammar from Selectors 3. In particular, no whitespace is allowed 
between a and its sign, nor between a and n. (Whitespace *is* allowed 
around the +/- sign after n, and around the whole an+b sequence.)

nth
   : S* [ ['-'|'+']? INTEGER? {N} [ S* ['-'|'+'] S* INTEGER ]? |
          ['-'|'+']? INTEGER | {O}{D}{D} | {E}{V}{E}{N} ] S*
   ;


For odd/even, the phrase used is "If repr contains an ASCII 
case-insensitive match for …" It should be "is" instead of "contains". 
:nth-child(Some oddities) should not match. ("Contains" is used that way 
later in the algorithm.)

-- 
Simon Sapin

Received on Friday, 1 February 2013 07:45:20 UTC