Allow -n in an-b, allow comments within +n and -n #1498
Conversation
|
The grammar does allow for What it doesn't allow is Chrome does not allow this, by the way: <!DOCTYPE html>
<p>foo<p>foo<p>foo
<style>p:nth-child( -/**/n + 2 ) { color: red; }</style>doesn't turn anything red, while |
|
Oh, and note that comments are allowed anywhere between two tokens. This is implicit in "consume a token" - whenever you ask for the next token, it automatically consumes (and silently discards) any comments as well. In Serialization, it's specified that impls are allowed to remember where comments were, and re-insert them during serialization if they wish, but this information must have no effect on parsing - as far as CSS parsing and grammars are concerned, comments don't exist. |
|
The initial message of this PR is misleading. This is specifically about the |
|
Sure, but I addressed that specifically in my response, too. Chrome does not allow |
|
Yeah, I hadn't misread the spec -- but I felt it should be symmetric. For some reason it seemed like Chrome accepted this? Maybe it was a separate case, I was doing a lot of testing to make Firefox match Chrome and the spec. Will remove this behavior from Firefox then. |
|
Theoretical purity (symmetry) doesn't apply when we're dealing with "what random-ass places in the middle of expressions can people put comments in?". ^_^ There's a lot of things like this that are just artifacts of CSS tokenization, not something meaningful. |
|
Fair. Firefox has a bajillion tests for "what random-ass places can folks put comments in", but I'm just going to remove the ones that test for this behavior and fix up the parsing to match this. |
|
Testing for those things is good; people will put them anywhere they're allowed, because users tessellate the possibility space of an API. But trying to make decisions about where to allow them based on aesthetics is not. ^_^ |
|
Agreed |
Currently the grammar doesn't allow for
-nwithin:nth-child, it only deals with+n. However,-n(and things like-n+5) are accepted by browsers.This fixes the discrepancy.
Additionally, the parsing here is a bit tricky -- while the
+/-andnare separate tokens, the spec does not allow for spaces between them. Chrome follows this, and as of https://bugzilla.mozilla.org/show_bug.cgi?id=1364009, firefox does too. However, both allow comments. While this is probably implicit, I'm clarifying this within the spec.See also: servo/rust-cssparser#153,
r? @tabatkins @SimonSapin