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: L. David Baron <dbaron@dbaron.org>
Date: Mon, 22 Apr 2013 09:27:45 -0400
To: www-style@w3.org
Message-ID: <20130422132745.GA5968@crum.dbaron.org>
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.)


𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                           http://www.mozilla.org/   𝄂
Received on Monday, 22 April 2013 13:28:12 UTC

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