By the way, I was wrong about this being broken. I was thinking we weren't dealing with the seed argument in selector-native, but it turns out we were. There's still a behavior difference due to the nature of QSA's scoping problem, but that pretty much requires Sizzle to fix.

There's still a behavior difference due to the nature of QSA's scoping problem, but that pretty much requires Sizzle to fix.

...or the new @gibson042's in-jQuery implementation that borrows some ideas from Sizzle but only as much as needed (see jquery/sizzle#293 (comment) for more info). But that's a plan for the next major.

At some point the DOM matches and findAll would help here, but nobody seems to be in a hurry to implement them.

Until we drop IE 11 (which will happen once we conquer Mars) we need all this parsing logic anyway.

...or the new @gibson042's in-jQuery implementation that borrows some ideas from Sizzle but only as much as needed (see jquery/sizzle#293 (comment) for more info). But that's a plan for the next major.

Or possibly later. Something I like about selector-native is that it doesn't even tokenize the selector, which would be required even in a streamlined engine. Rather than an in-jQuery implementation, I'd prefer to see a new version of Sizzle that drops all polyfills (for native selectors) and POS handling, and just manipulates the selector into something that can first go through qsa or matchesSelector, then filtered. Regardless, it won't be for 3.0, and it's something we can discuss later when the time comes.