The reasons that are often cited that make container queries difficult or impossible is things like infinite loops—e.g. changing the width of an element, invalidating a container query, which changes the width again, which makes the container query take effect, etc. But that was solved with containment. A “parent selector”, or :has as it is now been officially dubbed (I like it, that’s how jQuery rolled, although Adrian pointed out a tweet noting that it’s more versatile), has traditionally had similar problems. Things like requiring “multiple pass” rendering which is too slow to be acceptable.
Primarily, even without
:has()it’s pretty hard to live up to performance guarantees of CSS, where everything continue to evaluate and render “live” at 60fps. If you think, mathematically, about just how much work is conceptually involved in applying hundreds or thousands of rules as the DOM changes (including as it is parsing), it’s quite a feat as is.
Engines have figured out how to optimize this based on clever patterns and observations that avoid the work that is conceptually necessary – and a lot of that is sort of based on these subject invariants thathas()would appear to throw to the wind.
The fact that there is a spec now is super encouraging, and that it has Igalia’s eye on it. Apparently, some of the performance problems have either been surmounted or, through testing, determined to be negligible enough to remain a shippable feature.
Adrian Bece digs into it all!
The team at Igalia has worked on some notable web engine features like CSS grid and container queries, so there is a chance for
:hasselector to see the light of day, but there is still a long way to go.What makes relational selector one of the most requested features in the past few years and how are the developers working around the missing selector? In this article, we’re going to answer those questions and check out the early spec of
:hasselector and see how it should improve the styling workflow once it’s released.
Let’s cross our fingers. I’ve been watching this for 10 years and trying to document use cases.
YUGE use case:
Combining
:has()and CSS’s ever present (live) reactive nature, rules can be written to “anticipate” and then react to dynamically loaded data with child selectors and or attributes without the use of JavaScript.This promotes the Least Power Principle and a cleaner decoupling and separation of concerns .
Simple example… Only when these CSS rule becomes true will the loading animation go away and the parent container slide onto the screen.
I feel like every week a new article about the :has selector is posted here, and there’s never any new information either. As far as I’m concerned, until I see it in Canary it’s not worth any thought.