Re: Proposal: parent selectors

On 1/21/10 3:26 PM, François REMY wrote:
> The "cache" would contains every element matching "ul > li"
> because every of those element could potentially match the
> rule "ul:has(img) > li".

Ah, I see.  OK....

> If an element (supposedly a copy of b1) is added to #a, we need
> to check every child of #a that's in the "cache" list because it's
> possible that they now match the :has rule (or that they don't
> match anymore if we delete the newly inserted <li> that was
> containing the <img> tag).

So you're assuming that we allow :has(img) but not, say :has(p img)?  Or 
that the latter is somehow scoped?

But ok.  Any time an element is added to the DOM... how do we know what 
things in the cache list to check?

> Here, the cache would thus contains 6 elements. More optimisation
> would be allowed to only rerun the CSS matching algorithm when
> the DOM change that occued may have effect to the rule. A :hover
> added on an element of the DOM should not rerun the ul:has(img) > li
> rule, because this would have no incidence.

Sure.

> You're true. Optimisation may though detect that if no IMG tag were added
> (no removed) the state of the :has(img) will not change for any P.

In this case, sure.  In general, you have to check that none of the 
added/removed nodes match the selector inside the :has().  How expensive 
that is depends on how many nodes are involved and how expensive that 
selector is.

> Especially if an author choose to perform P:has(:hover) { color: gray; }

Oh, they will.  ;)

> But it will require many difference cases, and thuse an huge amount of
> code, which is not very acceptable, too.

Well, it might be.  But it does make it harder to quickly prototype the 
feature in a sane way.

-Boris

Received on Thursday, 21 January 2010 20:36:01 UTC