Bug 17248 – :nth-child() and :lang() should allow spaces before, after and inside the expression

• Status: RESOLVED
• Resolution: FIXED
• Component: CSS

fast/css/css3-nth-child.html is failing because :nth-child(-n + 2) fails to parse because of the spaces around the "+". According to the spec, spaces should be allowed before and after each part of the expression in the parentheses. Similarly, :lang() should allow leading and trailing space.

<rdar://problem/5733761>

[Dave Hyatt]

CSS WG is proposing to amend this so that whitespace is only allowed after the '(' and before the ')'.

HEre is the text of Daniel's email to www-style:

The CSS Working Group discussed today the grammar of the
:nth-child() and friends functional pseudo-classes included
in the Selectors spec. Because of the CSS lexical scanner,
parsing :nth-child(an+b) can be very complex if, as always
in CSS, we allow whitespaces everywhere, including between
the sign of a and its numeral part and so on.
We also would like at some point in the future to discuss
real math expressions in CSS, so we don't want to make today
choices that could be harmful to that future discussion.

We then propose to restrict whitespaces in the nth-child()'s
argument to ONLY after the '(' and before the ')'. Since this is not the
common practice in CSS - whitespace is usually allowed everywhere -
we would like the web designers community to let us know if
they think it's an acceptable compromise or if you think for
instance that web authors will make a lot of mistakes putting
invalid whitespaces inside the expression.

Thanks for your valuable feedback. Feel free to forward the question
as soon as the answer is sent to the mailing-list.

</Daniel>

[Yuzo Fujishima]

Created attachment 45956 [details]
Allow leading/trailing space for CSS nth-*() and lang()

[WebKit Review Bot]

style-queue ran check-webkit-style on attachment 45956 [details] without any errors.

[Darin Adler]

Comment on attachment 45956 [details]
Allow leading/trailing space for CSS nth-*() and lang()

New test cases would be better than changing existing ones. Why remove the testing of the no-spaces cases?

[Yuzo Fujishima]

Created attachment 46021 [details]
Allow leading/trailing space for CSS :nth-*() and :lang()

[Yuzo Fujishima]

Thank you for reviewing this.

I've added a dedicated test for this bug.
Can you take another look?

Yuzo

[WebKit Review Bot]

style-queue ran check-webkit-style on attachment 46021 [details] without any errors.

[Darin Adler]

Comment on attachment 46021 [details]
Allow leading/trailing space for CSS :nth-*() and :lang()

r=me

Two thoughts on how to improve in the future or with a followup:

    1) This doesn't need to be a non-text test. It would be good to make a test of this that dumps as text instead of a render tree. There are plenty of ways to check that CSS has been parsed other than actually dumping out the render tree.

    2) We should have a test of the "spaces inside the expression" case, even though we're not changing behavior of that. We want to test all the significant cases, and that clearly is significant, given the discussion in this bug.

[WebKit Commit Bot]

Comment on attachment 46021 [details]
Allow leading/trailing space for CSS :nth-*() and :lang()

Clearing flags on attachment: 46021

Committed r52943: <http://trac.webkit.org/changeset/52943>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Alexey Proskuryakov]

This was landed without pixel results. Please land those, or better yet, change the test to a dumpAsText one.