RE: CSS-ISSUE-320: Profile :matches() / :not() for fast vs. complete implementation [Selectors Level 4]

> What's the performance problem with combinators here? Allowing
> :not(div p) doesn't seem particularly worse than "div p" on its own
> (except that :not() in general can't use some of the filtering
> optimizations that we can use for "div p"); I think advanced authors
> are aware that such selectors can be slower.

This is something I already said in the past.

http://lists.w3.org/Archives/Public/www-style/2013Mar/0261.html :
@@ As for the reason of refusing :not(a b), it’s based on the (probably) 
@@ valid assumption that proving the existence of something is generally
@@ faster than proving it does not exist (NP vs coNP). However, since we
@@ don’t have any efficient algorithm for selector matching, the worst
@@ case of traditional selectors is already matching the complexity that
@@ :not(a b) could introduce and the sky hasn’t fallen yet, as far as I 
@@ know.
@@
@@ My bet would be to say that it’s not really a performance issue to 
@@ support complex selectors in :not() but I could be wrong due to 
@@ optimizations that would be impossible to make anymore and that I’m
@@ unaware of. If so, that would be interesting to know about them.

Maybe a good time to clarify?


> Or are you talking about allowing some use of combinators inside of
> :not() or :matches() that allows the "subject" to no longer be the
> last piece of the selector? (That's a separate distinction already
> made between the "fast" and "complete" profiles, though.)

Yep, it seems a really different beast to me.