What does the CSS :has() pseudo-class match, and why is it described as a relational or "parent" selector?

## The problem it solves Every combinator in CSS before `:has()` pointed downward or forward: descendant, child, next-sibling, subsequent-sibling. You could style a heading inside a card, never the card that contained a heading. "A parent selector" was the longest-standing request in CSS, and `:has()` is the answer — though the spec deliberately calls it *relational*, because containment is only one of the relationships it expresses. ## What it matches — the subject rule `:has()` is a pseudo-class attached to some element in the selector, and that element remains the **subject** of the rule. Compare: ```css .card img { border: 1px solid; } /* styles the img */ .card:has(img) { border: 1px solid; } /* styles the .card */ ``` The argument is evaluated *relative to* the element carrying `:has()`. If at least one element satisfies the relative selector, the outer element matches. Nothing inside the parentheses is styled. ## Relative selectors and combinators The argument is a **relative selector list**, meaning it may begin with a combinator; when it does not, a descendant combinator is implied: ```css li:has(> a) { } /* an li whose direct child is a link */ h2:has(+ p) { } /* an h2 immediately followed by a paragraph */ .row:has(~ .row) { } /* a row with any later sibling row */ section:has(table) { } /* a section containing a table at any depth */ ``` That sibling capability is what makes `:has()` more than a parent selector: `h2:has(+ p)` styles an element based on what comes *after* it, which no combinator could express. Multiple arguments are an OR — `.card:has(img, video)` matches a card containing either. To express AND, chain the calls: `.card:has(img):has(h2)`. ## Specificity `:has()` is weighted like `:is()`: it contributes the specificity of its **most specific argument**, plus whatever the rest of the selector scores. ```css article:has(#promo) { } /* (1,0,1) */ article:has(.promo) { } /* (0,1,1) */ :where(article):has(.promo) { } /* (0,1,0) — :where() zeroes only its own argument */ ``` So an ID buried inside `:has()` silently raises the whole rule's weight, exactly as it does inside `:is()`. ## Patterns that used to need JavaScript ```css /* Form field that contains an invalid control */ .field:has(:invalid) { border-color: crimson; } /* Label whose checkbox is checked */ label:has(input:checked) { font-weight: 700; } /* Lock page scrolling while a dialog is open */ body:has(dialog[open]) { overflow: hidden; } /* Layout that reacts to whether media is present */ .card:has(img) { grid-template-columns: 8rem 1fr; } /* Negation reads naturally when combined with :not() */ .card:not(:has(img)) { padding-block-start: 1rem; } ``` That last shape is worth internalising: `:not(:has(x))` means "does not contain an x", while `:has(:not(x))` means "contains something that is not an x" — a very different and usually unintended condition. ## Restrictions Three limits catch people out. `:has()` may not be nested inside another `:has()`. Pseudo-elements are not valid arguments, so `:has(::before)` does not work. And `:has()` cannot be attached after a pseudo-element. Unlike `:is()` and `:where()`, its selector list is **not forgiving**: an argument the browser cannot parse invalidates the whole selector, which is deliberate so that feature detection via `@supports selector(:has(a))` gives a meaningful answer. ## Cost Matching `:has()` requires the engine to consider descendants or siblings when deciding whether an ancestor matches, and the match can change as the subtree changes. Engines optimise this heavily and ordinary use is fine; the sensible discipline is to keep the argument narrow and anchored — `li:has(> a.active)` rather than `:has(.active)` applied to a very broad subject — and to avoid pairing an extremely general subject with a deep descendant argument. ## Support `:has()` shipped in Safari 15.4 (March 2022) and Chrome 105 (August 2022), with Firefox 121 (December 2023) completing support in major browsers. For codebases that still target older engines, guard the enhancement with `@supports selector(:has(a)) { … }` so the layout degrades rather than breaks.