The :has() pseudo-class is, hands-down, my favourite new CSS characteristic. I do know it’s for a lot of of you as nicely, no less than these of you who took the State of CSS survey. The power to jot down selectors the other way up offers us extra superpowers I’d by no means thought potential.
I say “extra superpowers” as a result of there have already been a ton of actually superb intelligent concepts revealed by a bunch of tremendous sensible folks, like:
This text isn’t a definitive information to :has(). It’s additionally not right here to regurgitate what’s already been stated. It’s simply me (hello 👋) leaping on the bandwagon for a second to share a number of the methods I’m more than likely to make use of :has() in my day-to-day work… that’s, as soon as it’s formally supported by Firefox which is imminent.
When that does occur, you may guess I’ll begin utilizing :has() far and wide. Listed here are some real-world examples of issues I’ve constructed not too long ago and thought to myself, “Gee, this’ll be a lot nicer as soon as :has() is absolutely supported.”
Keep away from having to succeed in exterior your JavaScript part
Have you ever ever constructed an interactive part that typically must have an effect on kinds someplace else on the web page? Take the next instance, the place <nav> is a mega menu, and opening it adjustments the colours of the <header> content material above it.
I really feel like I must do this sort of factor on a regular basis.
This specific instance is a React part I made for a website. I needed to “attain exterior” the React a part of the web page with doc.querySelector(...) and toggle a category on the <physique>, <header>, or one other part. That’s not the top of the world, however it certain feels a bit yuck. Even in a completely React website (a Subsequent.js website, say), I’d have to decide on between managing a menuIsOpen state approach greater up the part tree, or do the identical DOM ingredient choice — which isn’t very React-y.
With :has(), the issue goes away:
header:has(.megamenu--open) {
/* type the header otherwise if it incorporates
a component with the category ".megamenu--open"
*/
}No extra fidgeting with different components of the DOM in my JavaScript elements!
Higher desk striping UX
Including alternate row “stripes” to your tables is usually a good UX enchancment. They assist your eyes maintain observe of which row you’re on as you scan the desk.
However in my expertise, this doesn’t work nice on tables with simply two or three rows. In case you have, for instance, a desk with three rows within the <tbody> and also you’re “striping” each “even” row, you may find yourself with only one stripe. That’s probably not price a sample and might need customers questioning what’s so particular about that one highlighted row.
Utilizing this method the place Bramus makes use of :has() to use kinds based mostly on the variety of kids, we are able to apply tble stripes when there are greater than, say, three rows:
What to get fancier? You might additionally determine to solely do that if the desk has no less than a sure variety of columns, too:
desk:has(:is(td, th):nth-child(3)) {
/* solely do stuff if there are three or extra columns */
}Take away conditional class logic from templates
I typically want to vary a web page structure relying on what’s on the web page. Take the next Grid structure, the place the position of the principle content material adjustments grid areas relying on whether or not there’s a sidebar current.
That’s one thing which may depend upon whether or not there are sibling pages set within the CMS. I’d usually do that with template logic to conditionally add BEM modifier lessons to the structure wrapper to account for each layouts. That CSS would possibly look one thing like this (responsive guidelines and different stuff omitted for brevity):
/* m = major content material */
/* s = sidebar */
.standard-page--with-sidebar {
grid-template-areas: 's s s m m m m m m m m m';
}
.standard-page--without-sidebar {
grid-template-areas: '. m m m m m m m m m . .';
}CSS-wise, that is completely nice, after all. But it surely does make the template code a bit of messy. Relying in your templating language it could actually get fairly ugly to conditionally add a bunch of lessons, particularly if it’s a must to do that with a number of little one components too.
Distinction that with a :has()-based strategy:
/* m = major content material */
/* s = sidebar */
.standard-page:has(.sidebar) {
grid-template-areas: 's s s m m m m m m m m m';
}
.standard-page:not(:has(.sidebar)) {
grid-template-areas: '. m m m m m m m m m . .';
}Actually, that’s not an entire lot higher CSS-wise. However eradicating the conditional modifier lessons from the HTML template is a pleasant win for those who ask me.
It’s straightforward to consider micro design selections for :has() — like a card when it has a picture in it — however I believe it’ll be actually helpful for these macro structure adjustments too.
Higher specificity administration
Should you learn my final article, you’ll know I’m a stickler for specificity. If, like me, you don’t need your specificity scores blowing out when including :has() and :not() all through your kinds, make sure you use :the place().
That’s as a result of the specificity of :has() is predicated on essentially the most particular ingredient in its argument record. So, you probably have one thing like an ID in there, your selector goes to be powerful to override within the cascade.
Then again, the specificity of :the place() is all the time zero, by no means including to the specificity rating.
/* specificity rating: 0,1,0.
Identical as a .standard-page--with-sidebar
modifier class
*/
.standard-page:the place(:has(.sidebar)) {
/* and so on */
}The longer term’s vibrant
These are only a few issues I can’t wait to have the ability to use in manufacturing. The CSS-Tips Almanac has a bunch of examples, too. What are you wanting ahead to doing with :has()? What kind of some real-world examples have you ever run into the place :has() would have been the right resolution?
