User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:39.0) Gecko/20100101 Firefox/39.0 Build ID: 20150629114848 Steps to reproduce: Ran https://jsfiddle.net/catrope/h9bzsoeg/1/ : console.log( document.querySelector( 'input' ) ); console.log( document.querySelector( 'input::-moz-progress-bar' ) ); console.log( document.querySelector( 'input::-moz-progress-bars' ) ); Actual results: The first call returned the <input> element (correct). The second call returned null (correct). The third call threw an exception. Expected results: The third call should have returned null, not thrown an exception. According to http://dev.w3.org/2006/webapi/selectors-api/#grammar : "Authors are advised that while the use of pseudo-elements in selectors is permitted, they will not match any elements in the document, and thus would not result in any elements being returned. Therefore, authors are advised to avoid the use of pseudo-elements in selectors that are passed to the methods defined in this specification." This is also broken in WebKit, where even passing a -webkit prefixed pseudo-element causes an exception: https://bugs.webkit.org/show_bug.cgi?id=149160
The relevant part of the spec you link to is this, in <http://dev.w3.org/2006/webapi/selectors-api/#processing-selectors>: If result is invalid ([SELECT], section 12), raisea a SYNTAX_ERR exception ([DOM-LEVEL-3-CORE], section 1.4) and abort this algorithm. In this case, the selector is invalid, so you get an exception. The text you quoted applies in cases when the pseudo-element you use is one the UA recognizes as a valid pseudo-element. Which is why ::-moz-progress-bar does not throw but ::-moz-progress-bars does.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → INVALID
My bad, Firefox does indeed comply with the spec here. It turns out Chrome does the same thing. The Safari bug is different, because it barfs even on ::-webkit-* selectors.
You need to log in before you can comment on or make changes to this bug.