- From: François REMY <francois.remy.dev@outlook.com>
- Date: Mon, 22 Apr 2013 18:15:04 +0200
- 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