W3C home > Mailing lists > Public > www-style@w3.org > April 2013

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

From: FranÁois REMY <francois.remy.dev@outlook.com>
Date: Mon, 22 Apr 2013 18:15:04 +0200
Message-ID: <DUB120-W268DD90A7BC03DBB498801A5CB0@phx.gbl>
To: "L. David Baron" <dbaron@dbaron.org>, "www-style@w3.org" <www-style@w3.org>
> 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. 		 	   		  
Received on Monday, 22 April 2013 16:15:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:28 UTC