The CSS pseudo class is rolling out in many browsers with Chrome and Safari already fully supporting it. It’s often referred to it as “the parent selector” — as in, we can select style a parent element from a child selector — but there is so much more that can help us solve. One of those things is re-inventing the clickable card pattern many of us love to use from time to time.
We’ll take a look at how can help us handle linked cards, but first…
There is already a bunch of great posts floating around that do an excellent job explaining what is and what it’s used for, but it’s still new enough that we ought to say a few words about it here as well.
is a relational pseudo class that’s part of the W3C Selectors Level 4 working draft. That’s what the parentheses are all about: matching elements that are related to — or, more accurately, contain — certain child elements.
So, you can see why we might want to call it a “parent” selector. But we can also combine it with other functional pseudo classes to get more specific. Say we want to style articles that do not contain any images. We can combine the relational powers of with the negation powers of to do that:
But that’s just the start of how we can combine powers to do more with . Before we turn specifically to solving the clickable card conundrum, let’s look at a few ways we currently approach them without using .
There are three main approaches on how people create a fully clickable card these days and to fully understand the power of this pseudo class, it’s nice to have a bit of a round-up.
This approach is something used quite frequently. I never use this approach but I created a quick demo to demonstrate it:
There are a lot of concerns here, especially when it comes to accessibility. When users navigate your website using the rotor function, they will hear the full text inside of that element — the heading, the text, and the link. Someone might not want to sit through all that. We can do better. Since HTML5, we can nest block elements inside of an element. But it never feels right to me, especially for this reason.
Using JavaScript, we can attach a link to our card instead of writing it in the markup. I found this great CodePen demo by costdev who also made the card text selectable in the process:
This approach has a lot of benefits. Our links are accessible on focus and we can even select text. But there are some drawbacks when it comes to styling. If we want to animate those cards, for example, we would have to add styles on our main wrapper instead of the link itself. We also would not benefit from the animations when the links are in focus from keyboard tabbing.
This method requires us to set the card with relative positioning, then set absolute positioning on the link’s pseudo selector of a link. This doesn’t require any JavaScript and is pretty easy to implement:
There are a few drawbacks here, especially when it comes to selecting text. Unless you provide a higher z-index on your card-body, you won’t be able to select text but if you do, be warned that clicking the text will not activate your link. Whether or not you want selectable text is up to you. I think it can be a UX issue, but it depends on the use-case. The text is still accessible to screen readers but my main problem with the method is the lack of animation possibilities.
Now that we’ve established the existing approaches for clickable cards, I want to show how introducing to the mix solves most of those shortcomings.
In fact, let’s base this approach on the last one we looked at using on the link element. We can actually use there to overcome that approach’s animation constraints.
I will be keeping things as simple as possible by targeting elements in the CSS instead of classes.
For this demo, we’re going to add an image zoom and shadow to the card on hover, and animate the link with an arrow popping up and while changing the link’s text color. To make this easy, we’re going to add some custom properties scoped on our card. Here’s the basic styling:
Great! We added an initial scale for the image (), the initial color of the card heading () and some extra properties we will use to make our arrow pop out of the link. We’ve also set an empty state of the declaration in order to animate it later . This sets up what we need for the clickable card right now, so let’s add some resets and styling to it by adding those custom properties to the elements we want to animate:
Let’s be kind to people and also add a screen reader class hidden behind the link:
Our card is starting to look pretty sweet. It’s time to add a bit of magic to it. With the pseudo class, we can now check if our link is hovered or focused, then update our custom properties and add a . With this little chunk of CSS our card really comes to life:
See what’s up there? Now we get the updated styles if any child element in the card is hovered or focused. And even though the link element is the only thing that can contain a hover or focus state in the clickable card approach, we can use that to match the parent element and apply the transitions.
And there you have it. Just another powerful use case for the selector. Not only can we match a parent element by declaring other elements as arguments, but we can match also use pseudos to match and style parents as well.
Here is a demo using this technique. You might notice an extra wrapper around the card, but that’s just me playing around with container queries, which is just one of those other fantastic things rolling out in all major browsers.
Got some other examples you wish to share? Other solutions or ideas are more than welcome in the comment section.