- From: Kang-Hao (Kenny) Lu <kennyluck@csail.mit.edu>
- Date: Sat, 04 Feb 2012 23:58:49 +0800
- To: WWW Style <www-style@w3.org>, WebApps Working Group <public-webapps@w3.org>
- CC: Boris Zbarsky <bzbarsky@MIT.EDU>
(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 document.querySelector("*:not(xxx") FF10, IE9, Opera12alpha: don't throw WebKit: throw document.querySelector("*:nth-child(n") IE9, Opera12alpha: don't throw FF10, WebKit: throw document.querySelector("[xxx") 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. Cheers, Kenny
Received on Saturday, 4 February 2012 15:59:17 UTC