Not sure if spec, test or implementation bug.
So I see a few classes of failures: 1) The test is doing things like: foo.matches(">*") due to running runMatchesTest("In-document", doc, scopedSelectors, "html"); The big comment in http://w3c-test.org/dom/nodes/selectors.js claims "These selectors are intended to be used with the find(), findAll() and matches() methods." What the spec says for matches() is at https://dom.spec.whatwg.org/#dom-element-matches and is: Let s be the result of parse a selector from selectors. [SELECTORS] If s is failure, throw a SyntaxError. Per http://dev.w3.org/csswg/selectors/#parse-a-selector the string ">*" is not valid. It would be valid per <http://dev.w3.org/csswg/selectors/#parse-relative-selector>, I think. This part clearly looks like a test bug to me. I think TEST_MATCH should not be set for any of those selectors in scopedSelectors. 2) The test does something.matches("*", somethingElse) and expects that to act as a scoped selector and match the "something" if it's a descendant of "somethingElse". But per spec matches() does not take a second context argument. This is a test bug; this test should not be flagged TEST_MATCH. In fact, having TEST_MATCH on any of the scopedSelectors is pretty suspect; those that pass more or less do so by accident, afaict. 3) Some of the non-ASCII tests under scopedSelectors are failing. They're failing because someone fucked up and didn't read the "Caution: If copying and pasting the folowing non-ASCII classes, ensure unicode normalisation is not performed in the process" comment prominently placed in the validSelectors non-ASCII bits and the similar one for IDs. Specifically, the HTML has Táiběi in the class/ID with the á encoded in UTF-8 as 0x61 0xCC 0x81 (an "a" followed by U+0301 COMBINING ACUTE ACCENT) and has the "ě" likewise encoded as an "e" followed by a combining mark. The same is true of the validSelectors tests in the JS. But the scopedSelectors tests have the "á" encoded as 0xC3 0xA1, which is U+00E1 LATIN SMALL LETTER A WITH ACUTE, and similar combined char for the "ě". This, too, is clearly a test bug.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → INVALID
In earlier drafts of the Selectors API 2 spec, matches() did take a relative selector and did take a second argument for refNodes. See the old WG NOTE. http://www.w3.org/TR/selectors-api2/ It appears this has been changed in the more recent DOM spec that superseded Selectors API 2. So the tests were valid at the time I wrote them, but that spec change makes them invalid.
You need to log in before you can comment on or make changes to this bug.