- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 22 Apr 2013 09:21:12 -0700
- To: "L. David Baron" <dbaron@dbaron.org>
- Cc: www-style list <www-style@w3.org>
On Mon, Apr 22, 2013 at 6:27 AM, L. David Baron <dbaron@dbaron.org> wrote: > 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. You tell me. ^_^ I thought we had pushback from implementors on allowing that. If y'all are okay with complex selectors in :not()/:matches(), great! > 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.) Nah, the subject indicator is definitely still in the complete profile only for now. ~TJ
Received on Monday, 22 April 2013 16:22:01 UTC