CSS :has() Selector Playground — Free HTML CSS JS Snippet

For as long as CSS has existed, selectors could only look downward or sideways — you could style a child based on its parent's class, or a sibling based on the element before it, but you could never style a parent based on what was happening inside it. That gap closed with the :has() relational pseudo-class, sometimes nicknamed the "parent selector," which shipped in all major browsers (Chrome, Edge, Safari, Firefox 121+) through 2023 and is now considered baseline-safe for 2025/2026 production work. This playground demonstrates two real, common UI problems that :has() solves without a single line of JavaScript state management.

How :has() works technically

:has() takes a relative selector argument and matches any element that contains at least one descendant matching that argument. Written as A:has(B), it selects A if A contains B anywhere in its subtree (not just as a direct child, unless you scope it with the child combinator like :has(> B)). Critically, :has() can reference pseudo-classes on the descendant, such as :checked, :invalid, :focus, or :disabled — meaning the parent's appearance can react live to the interactive state of an input buried inside it. This is the mechanism behind both demos above: .plan-card:has(input:checked) matches a card label the instant its internal radio button becomes checked, and fieldset:has(input:invalid:not(:placeholder-shown)) matches the fieldset the instant any field inside it fails HTML validation after the user has typed something.

Why this matters for modern UI development

Before :has(), both of these effects required JavaScript: an event listener on every radio button to add/remove a "selected" class on its parent card, and a submit or input listener to toggle a warning banner's visibility based on aggregated validity across multiple fields. That JavaScript had to stay in sync with the DOM, handle edge cases like programmatic value changes, and re-run on every relevant event. With :has(), the browser's own style engine does this work — the rule re-evaluates automatically whenever the matched state changes, with no listeners, no reflow thrashing from manual class toggles, and no risk of the visual state drifting out of sync with the actual DOM state. This is a meaningful simplification for form-heavy dashboards, pricing pages, and settings panels where "does this container have an active/invalid/checked descendant" is an extremely common question to answer visually.

The card selection pattern

The card grid wraps each <input type="radio"> inside a <label class="plan-card">, which is itself already a common accessibility pattern — clicking anywhere on the label toggles the input. Layering :has(input:checked) on top means the selected-state border, background tint, and checkmark icon are pure CSS side effects of that native radio behavior, keyboard navigation (arrow keys move between radios in a group) included for free.

The form validity pattern

The signup fieldset combines :invalid (from the browser's built-in constraint validation, driven by type="email", required, and minlength="8") with :not(:placeholder-shown) — a trick that suppresses the invalid style until the user has actually typed something, avoiding the jarring experience of a form that looks broken before you've touched it. fieldset:has(...) then promotes that single-field state up to the whole group, showing an aggregate warning banner.

Browser support caveats

:has() has shipped in Chrome/Edge 105+, Safari 15.4+, and Firefox 121+ (December 2023), giving it broad coverage today, but any project supporting older Firefox ESR or legacy Safari should feature-detect with CSS.supports("selector(:has(a))") and provide a JavaScript fallback for critical UI.