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

On Thursday 2013-04-04 00:51 +0000, Cascading Style Sheets (CSS) Working Group Issue Tracker wrote:
> CSS-ISSUE-320: Profile :matches() / :not() for fast vs. complete implementation [Selectors Level 4]
> 
> http://www.w3.org/Style/CSS/Tracker/issues/320
> 
> Raised by: Elika Etemad
> On product: Selectors Level 4
> 
> People keep being confused about :matches() and :not()'s intention
> to allow full complex selectors. The only reason they're not
> allowed is perf, so let's just make two profiles for Selectors and
> let things like Selectors API and PDF processors implement the
> full version.

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.

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.)

-David

-- 
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                           http://www.mozilla.org/   𝄂

Received on Monday, 22 April 2013 13:28:12 UTC