[selectors-4] Clarity about whitespace between :nth-child()'s "of" and "S"

[zrhoffman]

Should things like :nth-child(1 of/* my comment */body) or :nth-child(1 of.c) parse?

From CSS Syntax 3:

csswg-drafts/css-syntax-3/Overview.bs

Lines 3324 to 3328 in 7e7ead7

	<<whitespace-token>> is never indicated in the grammar;
	<<whitespace-token>>s are allowed before, after, and between any two tokens,
	unless explicitly specified otherwise in prose definitions.
	(For example, if the prelude of a rule is a selector,
	whitespace is significant.)

I was unable to find any mention of whitespace being required for of S in the CSS Selectors 4 :nth-child() pseudo-class or :nth-last-child() pseudo-class sections.

So should <ident-token "of"> <complex-real-selector-list> parse?

• If not, the CSS Selectors 4 :nth-child() and :nth-last-child() prose would probably benefit from clarification.

• If so, some examples would be nice.

[fantasai]

https://www.w3.org/TR/selectors-4/#grammar defines white space requirements for selectors, but you're right, it doesn't seem to indicate whether whitespace is required around of. Probably it should be.

[tabatkins]

The parsing is clear - :nth-child(1 of.c) is perfectly valid and equivalent to :nth-child(1 of .c). Its terrible and you shouldn't write it, but the parsing and behavior is well-defined.

[zrhoffman]

Tests for this case added in web-platform-tests/wpt#37797

[nt1m]

@fantasai @tabatkins Is there a reason to not require one? WebKit requires one, and although it'd be easy to change that, I think that'd be unfortunate.

The fact that :nth-child(1 ofdiv) is invalid, but :nth-child(1 of.div) is valid, feels a bit off to me. Though looking at @zrhoffman's testcase, I guess one use-case is adding a comment between the of and the selector.

[tabatkins]

There's no particular reason to not require one, but the general policy across all of CSS is that whitespace is always optional, and I'm mildly opposed to adding one-off requirements for it unless there's a good reason; it just makes the language slightly less consistent. (And we probably can't add a general requirement for whitespace between tokens, because I suspect minifiers exist that take advantage of the current rules.)

There's not really a "use-case" either way, it's just that comments are a guaranteed way to force a tokenization boundary without whitespace, so we usually reach for them when showing off the parsing. ^_^