Re: Proposal: parent selectors

On 1/21/10 1:12 PM, François REMY wrote:
> The :has pseudo-class would not be often used for drastical
> changes. So, we're applying :has on elements of the DOM
> that doesn't contains many elements. This would 'mitigate'
> the problem in most of cases since those elements are not
> often subject to DOM changes.

I'm not sure I follow....

If you use :has, then depending on the structure of your selectors any 
DOM change anywhere in the document can affect the style of any other 
element in the document.  So the general solution to have correct 
styling is to have all DOM changes restyle the whole document.

It sounds like you're proposing a specific optimization to avoid doing 
that.  What is the optimization, though?

> For the other cases, though, it would be possible to build
> a sort of cache. When an element is matching a :has rule
> (or is only failing a :has part) we add it into a cache list. When
> the DOM is modified into an element included in that list

Or any of it's descendants. Which means that for any DOM modification 
one needs to check whether the element is a descendant of something in 
the list, right?

This would possibly work; it could have incredibly bad performance and 
memory consumption in some cases.  For example any time :has() is used 
without anything in front of it (since in that case all elements in the 
DOM end up in the list).

As I said, with enough memory bloat and code complexity one can work out 
a way to make this not suck in general...

> This would be very efficient, at least if the number of potential
> elements matching :has rules is kept small. If not, it may lead
> to a higher memory usage, and sightly slow down the page.
> But this situation would not occur in 99% of the cases.

I fully expect unqualified :has() usage to be a significant fraction of 
:has() usage if the selector is implemented.

> (BTW, if has-child is acceptable, I don't see any reason why :has
> would not be acceptable since has-child also break the UA's CSS
> optimisations.)

It doesn't break them any more than existing selectors like :last-child, 
:first-child, :nth-*, and :empty already do, to a first approximation.

> Comme use cases would be :
> p:has(img), form:has(:focus), .contexMenu:has(:hover), ...

So that first one puts every <p> in the document in the list, right? 
Then every DOM mutation has to check whether any parent node of the 
thing being mutated is any of those <p>s.

For a typical document (with sections and paragraphs) that means that 
just the list-checking is comparable in number of operations (though not 
in memory access pattern, which might help) to walking over the whole 
document...

-Boris

Received on Thursday, 21 January 2010 18:40:54 UTC