selector:has(relative-selector) { \/* styles for selector *\/ }<\/code><\/pre>\n\n\n\n:has()<\/code> takes a selector (or a comma-separated list of them) and matches the element it’s attached to if<\/em> that inner selector finds something relative to it \u2014 a descendant by default, or a sibling if you give it a combinator. It never styles the thing found inside the parentheses; it only ever decides whether the outer element matches. In demo #1 below, .planCard:has(input:checked)<\/code> reads as “any .planCard<\/code> that has a checked input somewhere inside it” \u2014 and the border, background, and checkmark that then get styled all belong to .planCard<\/code>, never to the input itself.<\/p>\n\n\n\nWhy every demo here is something you click, not drag<\/h2>\n\n\n\n
These demos aren’t draggable sliders, because :has()<\/code> doesn’t respond to size \u2014 it responds to the DOM: a checkbox getting checked, an input becoming invalid, a child element being added or removed, a sibling being hovered. So each demo below is wired to whatever interaction actually triggers its rule: click a card, type in a field, hover a step, add a tile.<\/p>\n\n\n\nOne thing worth knowing about how these are built: the JavaScript in every demo only ever reports<\/em> what’s happening into the small readout under each one \u2014 it counts checked boxes, reads a field’s validity, counts child elements. It never sets the class or style that produces the visual effect. That part is left entirely to the :has()<\/code> rule shown in the code tag below each demo, so what you’re watching react is genuinely the CSS, not a script pretending to be one.<\/p>\n\n\n\n1. Selectable Plan Card<\/h2>\n\n\n\n
Click a pricing card and the whole card \u2014 border, background, checkmark \u2014 reacts to its own radio input being checked, no JavaScript required for the styling.<\/p>\n\n\n\n