RE: [CSSWG] Resolutions 2008-03-04 and 2008-03-11

Currently we are lucky that what we put there tokenizes correctly at all. If you want to pass the content off to another parser with no tokenization then we need either:

1)      A way to mark such content that you don't parse, since it could inconsistently use block scope characters, contain valid characters that would need to be escaped to be CSS compliant, etc...

2)      Make it a string. Strings are perfect. They imply, this content need not be munged at this time and will be handed to the function directly. Given this we might want rules on how to take the string and normalize it so it could be fed back through a CSS tokenizer implementation that was potentially augmented with a couple of additional rules, but not rules that then compete with the root CSS grammar and end up being required for all parsing.

Currently strings are the only format where you can get away with anything and not have it lead to buggy behavior introduced by the user agent. For instance, our filter: property in IE is not easily tokenizable. It winds up having a bunch of bare characters and we treat these as unknown tokens because there is no token in the spec that specifically relies on them. This works perfectly fine except for the opening ( paren which turns out to not be part of a function but instead is part of the preceding "class" token. Once this happens error recovery is out the window. We'll likely revise our implementation to accept string instead so the content goes unparsed and doesn't adhere to CSS error recovery and grammar.

Justin Rogers [MSFT]

From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of Brad Kemper
Sent: Wednesday, March 12, 2008 8:56 AM
To: Christoph Päper
Cc: www-style Mailing List
Subject: Re: [CSSWG] Resolutions 2008-03-04 and 2008-03-11


On Mar 12, 2008, at 3:59 AM, Christoph Päper wrote:
Also ':nth-child()' etc. probably will mostly be used with 'odd' and 'even'.

I don't know that that is true. I will probably use it a lot to select single elements when the HTML I don't control does not have IDs or classes where I need them.



I personally wouldn't expect there to ever be space between the "2" and the "n".



I would, if "2n" was expandable to "2*n": "2 * n", "2* n", "2 *n", "2 n".



David Baron proposed this earlier:



  Legal Examples:

    :nth-child( 3n + 1 )

    :nth-child( +3n - 2 )

    :nth-child( -n+ 6)

    :nth-child( +6 )

  Illegal Examples:

    :nth-child(3 n)

    :nth-child(+ 2n)

    :nth-child(+ 2)



Imagine making the addition (including its operator symbol) implied, just like the multiplication. Which of the following should be legal?



  :nth-child(3n1)     -> :nth-child(3n+1)

  :nth-child(3n 1)    -> :nth-child(3n+1)

  :nth-child(3n +1)   -> :nth-child(3n+1)

  :nth-child(3n -1)   -> :nth-child(3n-1)

  :nth-child(+3n 1)   -> :nth-child(3n+1)

  :nth-child(+3n +1)  -> :nth-child(3n+1)

  :nth-child(+3n -1)  -> :nth-child(3n-1)

  :nth-child(-3n 1)   -> :nth-child(-3n+1)

  :nth-child(-3n +1)  -> :nth-child(-3n+1)

  :nth-child(-3n -1)  -> :nth-child(-3n-1)

  :nth-child(3n + -1) -> :nth-child(3n-1)

  :nth-child(3n+ -1)  -> :nth-child(3n-1)

  :nth-child(3n +-1)  -> :nth-child(3n-1)

  :nth-child(3n+-1)   -> :nth-child(3n-1)

In mathematical notation, writing the number and variable together ("3n", "2pi", etc.) is the same as writing them with a multiplication symbol ("3*n", "2*pi", etc.). But substituting a space a multiplication symbol ("3 n") does not mean the same thing, so that is what I meant by saying I would not ever expect there to be space between the "2" and the "n".

For the same reasoning, I don't think you can imply the +/- symbol, because it stops making sense in mathematical notation. This really is a mathematical formula, where "n" is the progressively larger number representing the number of times repeated so far, starting with zero and increasing by one with each iteration (when using "+"). For each value of "n", solving the formula tells you which child number to apply the style to. If you replace the plus with a space (3n 1), then it stops making sense as a math formula, at least in my knowledge of mathematical notation.

I think the spec is not really that clear on the fact that this really is a mathematical formula in which n = {0,1,2,3,4...}, where solving the equation gives you the child number (assuming the child elements are numbered starting with 1). It never really comes out and says it that explicitly, even though it gives examples where a=1 or b=0 or a is negative, etc. and the math continues to work.

It seems to me that the entire contents of the parentheses could just be fed to a mathematical parser instead of tokenizing as units or whatever. If that was the case, then ":nth-child(3n+ -1)" should be allowed, as should other equivalencies that can be written with the same symbols, such as ":nth-child(-1 + 3n)".