Re: [selectors4][css3-syntax] should document.querySelector("html /* ") throw? (and some editorial comments)

(12/02/04 10:50), Boris Zbarsky wrote:
> On 2/3/12 8:52 PM, Kang-Hao (Kenny) Lu wrote:
>>    # Unexpected end of style sheet. User agents must close all open
>>    # constructs (for example: blocks, parentheses, brackets, rules,
>>    # strings, and comments) at the end of the style sheet. For example:
> ...
>> IE9, FF9.0.1, Opera12alpha don't throw in this case, but Chromium 18 and
>> Safari 5.1 do throw.
> That's presumably because WebKit generally doesn't implement the
> above-quoted provision about end-of-stylesheet. 

Indeed, some other similar cases

FF10, IE9, Opera12alpha: don't throw
WebKit: throw

IE9, Opera12alpha: don't throw
FF10, WebKit: throw

IE9: don't throw
FF10, Webkit, Opera12alpha: throw

They are all different slightly :(, although the test suite for
Selectors Level 1 is friendly enough to not include these :)

> [snip]
>> I don't have an opinion as to which is more correct
>> as this example is contrived anyway, but I think the spec should say
>> something about it, even if it's an "undefined".
> Agreed, but it shoul also be made clear how the Selectors API parsing
> does or doesn't coincide with CSS parsing.  Especially because
> Selectors API wants to change the parsing rules for its arguments so
> they no longer quite match the CSS ones... Putting webapps back on the
> cc list for that reason.

So the short term solution is to say whether the end of a DOMString
counts as end-of-stylesheet and whether the end-of-stylesheet rule
applies here, and the long term question is to determine whether we want
to move all syntax related parts (6.4 and the first half of 6.5) to
Selectors4 now that :scope is defined there.

Are there more inconsistency between Selectors4 and Selectors API 2? I
know Selectors API 2 needs to say something about the DOMString →
Unicode conversion (i.e. surrogates). That's again, quite
nitty...(haven't tested yet)

== some more editorial feedback for Selectors 4 ==

4.3. The Negation Pseudo-class: ‘:not()’

  # In Selectors Level 4, only compound selectors are allowed within
  # :matches(): combinators are not allowed. 

s/matches/not/ , presumably copypasta

3.4. Pseudo-elements

After you describe where a pseudo-element can appear, you should say the
rest of the situations are invalid (and ideally crossed link to the
section of invalid selectors).

4.2. The Matches-Any Pseudo-class: ‘:matches()’
4.3 The Matches-Any Pseudo-class: ‘:matches()’

(Ideally, xref the term "invalid" to the section of invalid selectors)

16. Formal Syntax (again)

  # Note that pseudo-elements are restricted to one per selector and
  # occur only in the last compound_selector.

as compared the relevant part in the section of pseudo elements

  # Only one pseudo-element may appear per selector, and only if the
  # subject of the selector is the last compound selector in the selector.
  # If present the pseudo-element must appear after the compound
  # selector that represents the subjects of the selector.

doesn't mention *::before.xx, which is neither valid in CSS3 nor CSS4
(this sentence has been like this since CSS3, and I think I might not be
the only person who got computed here). I believe having an incomplete
description is worse than having no description at all. Since CSS4
complicates this even more by introducing ::before:hover, I think you
might want to say

  | See Pseudo-elements (linked) for further restrictions on the syntax.

or if possible, change the compound_selector production.


Received on Saturday, 4 February 2012 15:58:56 UTC