W3C home > Mailing lists > Public > www-style@w3.org > July 2008

Re: Proposal for limited :matches pseudoclass

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 31 Jul 2008 18:00:01 -0500
Message-ID: <dd0fbad0807311600l7cda5b05v156622251f8eeb2c@mail.gmail.com>
To: Simetrical <simetrical@gmail.com>
Cc: "www-style list" <www-style@w3.org>
On Thu, Jul 31, 2008 at 5:52 PM, Simetrical <simetrical@gmail.com> wrote:

> On Thu, Jul 31, 2008 at 6:21 PM, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
> > I'm not sure I get you here.  Given "foo + bar", a DOM mutation could
> > certainly recompute the style of descendants.  It would simply be the
> > descendants of bar that possibly get recomputed styles, whereas in
> > foo:matches(+ bar) it's foo's descendants that may need recomputation.
>  Is
> > there something I'm overlooking here that allows you to avoid recomputing
> > styles upon a DOM mutation if you use the "foo + bar" rule?
> It depends on the mutation, I guess.  If you were to insert a new
> "bar" after foo, which is a very common case (right?), it would have
> no descendants that need to be recomputed.  If you were to delete a
> "bar" after foo, again, no recomputation for descendants.  Only if you
> change an element after foo that already has descendants to match
> "bar" will you need to recompute "bar"'s descendants.  But in all
> three cases you would have to recompute the descendants of "foo".
> Of course, you could also change the element before bar to match foo.
> In this case I guess it's reversed: you'll then have to recompute all
> of bar's descendants for "foo + bar", but for "foo:matches(+ bar)"
> you'd only have to recompute foo and its descendants, which is no
> extra cost.  I guess that's what you're saying.

Got it there at the end.  The + and ~ combinators seem to be naturally
symmetric, thus whether you match forward or backward doesn't seem to make a
difference in the complexity (to me, at least).

> I don't really know.  Maybe I don't understand after all.  Or maybe
> this isn't a problem at all for sibling selectors, only child or
> descendant selectors.

Assuming there are problems (which has been argued convincingly), I do
believe they would *only* appear with the child and descendant combinators.
It's my hope that the child combinator, at least, would still be acceptable
to implement.

Received on Thursday, 31 July 2008 23:12:57 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:38 UTC