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>
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>
Created attachment 45956 [details] Allow leading/trailing space for CSS nth-*() and lang()
style-queue ran check-webkit-style on attachment 45956 [details] without any errors.
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?
Created attachment 46021 [details] Allow leading/trailing space for CSS :nth-*() and :lang()
Thank you for reviewing this. I've added a dedicated test for this bug. Can you take another look? Yuzo
style-queue ran check-webkit-style on attachment 46021 [details] without any errors.
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.
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>
All reviewed patches have been landed. Closing bug.
This was landed without pixel results. Please land those, or better yet, change the test to a dumpAsText one.