Re: [csswg-drafts] [css-selectors] has-child selector (#4903)

> PrinceXML has already implemented :has() as currently specified and is shipping, and we have too (but are't shiipping yet).

Yes, printing implementations *can* implement :has() reasonably; the problem with :has() is that it means the style of an element can be affected by the qualities of *any element on the entire page*, and so progressive rendering and efficient updates become vastly more difficult and/or expensive to do.

If your implementation isn't bound by web reality in having to get  correct pixels on screen during loading and after each mutation *absolutely ASAP*, then the downsides aren't killer, and :has() is a nice useful feature.

> [Sebastian's suggestions]

No simplification of :has() that still allows arbitrary combinators is likely to have a noticeable effect on the perf. It's not the cost of evaluating the selector that's killer, it's the number of elements that have to be re-evaluated on every mutation. Currently it's all the descendants of the mutated element's parent; they're the only elements that can observe the mutation with today's selectors.  :has() makes the entire document potentially able to observe the mutation.

:has-child() widens the set of possibly-reacting elements to all the descendants of the mutated element's *grandparent*, which can be a considerably larger set, but is still much less than the entire document.

> From my experience folks exclusively mean ancestor querying. Eg, they want a child to own how it responds to a class or state findable further up the DOM. @bkardell had it right when using the < character, as a way of visualizing the intent .dark < .my-component {...}.

I'm not sure what you mean here - you seem to be talking about normal descendant combinators.

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4903#issuecomment-608590598 using your GitHub account

Received on Friday, 3 April 2020 18:22:07 UTC