> 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.3.1 : Monday, 2 May 2016 14:39:10 UTC