[csswg-drafts] [selectors][css-syntax] "parse a selector" missing trailing parenthesis

gsnedders has just created a new issue for 
https://github.com/w3c/csswg-drafts:

== [selectors][css-syntax] "parse a selector" missing trailing 
parenthesis ==
This is really @oyvind-stenhaug's issue, but hey. :)

Given an instruction to [parse a 
selector](https://drafts.csswg.org/selectors-4/#parse-selector) where 
the source is `:not([class]`, should this return failure or the 
selector? Notably, myself and @tabatkins seem to disagree on this.

Notably, step one of "parse a selector" is "Let selector be the result
 of parsing source as a <selector-list>. If it does not match the 
grammar, return failure.".

So, does `:not([class]` match the grammar?

* We start at `<selector-list>`, so we match against 
`<complex-selector-list>`
* Match against `<complex-selector>#`
* Match against `<compound-selector>`
* Match against `<simple-selector>+`
* None of `<type-selector>`, `<id-selector>`, `<class-selector>`, 
`<attribute-selector>` match the first char, so match against 
`<pseudo-class-selector>`
* Match against `':' <function-token> <any-value> ')'`, which is all 
fine and well until we need to match the `')'`. Now the **first big 
question** is what exactly we do when we hit `<function-token>`? The 
cross-reference links to 
[this](https://drafts.csswg.org/css-syntax-3/#typedef-function-token) 
which doesn't directly include a grammar, language, or machine. Do we 
"consume a token" until one is emitted, and if it is a 
`<function-token>` continue to match against that fragment of the 
grammar and if it is not try the next possible alternation or, if none
 exists, fail?

Regardless, following the grammar, we end up not matching, so we 
should return failure.

Now, per @tabatkins, this isn't the intent. Apparently, 
<https://drafts.csswg.org/css-syntax/#rule-defs> should apply, and 
specifically:

> When defining a function or a block, the ending token must be 
specified in the grammar, but if it’s not present in the eventual 
token stream, it still matches.

However, Selectors provides a grammar to match against, and gives no 
indication that there should be any error handling done if 
`<selector-list>` does not directly match. Selectors only refers to 
specific tokens from Syntax, and hence it isn't obvious that anything 
outwith "consume a token" applies to the grammar specified in 
Selectors, such as whether `':' <function-token> <any-value> ')'` is 
considered to define "a function".

I guess what would satisfy me for this (I'll let Øyvind speak for 
himself!) is text similar to what we have in Media Queries:

> Informal descriptions of the media query syntax appear in the prose 
and railroad diagrams in previous sections. The formal media query 
syntax is described in this section, with the rule/property grammar 
syntax defined in  [CSS3SYN] and [CSS3VAL].

Obviously we don't need quite that, perhaps something more like:

> The formal selector syntax is described in this section, with the 
rule grammar syntax defined in [CSS3SYN].

This clarifies the status of the grammar by providing a normative 
reference to [CSS3SYN], and makes it clear that "Defining Grammars for
 Rules and Other Values" in it applies to that grammar.

Obviously this doesn't deal with the other two issues: what exactly 
one does when one hits `<function-token>` in the grammar, and what is 
considered to define a function.

Please view or discuss this issue at 
https://github.com/w3c/csswg-drafts/issues/492 using your GitHub 
account

Received on Thursday, 15 September 2016 19:38:34 UTC