Unresolved Cross-Browser Behavior of CSS ':has()' with ':not()' and ':is()' Combinators

Answer first

Confirmed: Chrome/Edge on Blink and Safari on WebKit ship :has() in stable releases and parse :not() and :is() inside :has(). Firefox stable has historically been the gap for :has() support and must be verified against the exact release you target as of 2026-10-17. Selectors Level 4 permits :has() in any selector context and does not authorize implementation variance for combinations with :not() or :is(); divergent parsing is an implementation bug, not spec-allowed flexibility.

Likely explanation for layout differences you see: the semantics of the selector change, not just browser support. div:has(:not(.foo)) matches a div that contains any element not matching .foo. div:not(:has(.foo)) matches a div that contains no .foo descendants. Those are not equivalent and will produce different layouts even in browsers that parse both.

Confirmed facts

• Spec: :has() is a relational pseudo-class allowed anywhere a selector is allowed. :not() and :is() can appear inside the :has() argument and in the outer selector chain.
• Engines: Blink and WebKit implement :has() with :not() and :is() in current stable lines. Firefox support is the unresolved variable and requires current verification.
• Performance: :has() forces descendant evaluation for candidate elements. Cost grows with DOM size and nesting depth and with mutation frequency.

Likely explanation for inconsistencies

• Parsing vs semantics: Browsers may accept section:is(.bar) > :has(.baz) syntactically, but deep nesting with multiple relational pseudo-classes is a known edge area where implementation details differ.
• Negation confusion: :has(:not(.foo)) is often written when :not(:has(.foo)) was intended. The former matches if any non-.foo child exists, which is almost always true.

Steps needed for this case

1. Verify parsing support in target browsers:

   @supports selector(:has(*)) { /* :has() parses */ }

   try { document.querySelector('div:has(:not(.foo))'); } catch(e) { /* not parsed */ }

2. Verify semantics, not just parsing. Render identical markup with div:has(:not(.foo)) and div:not(:has(.foo)) and compare computed styles.
3. Rewrite negation to the intended form. Use :not(:has(.foo)) for “no .foo descendant”, not :has(:not(.foo)).
4. Guard critical layout with feature detection and class fallback:

   @supports selector(:has(*)) {
     .target:has(.child) { /* modern */ }
   }
   .no-has .target.has-child-fallback { /* JS-added class */ }

5. Measure style recalc cost on a representative large nested tree in dev tools while adding/removing nodes matched by the complex selector. Avoid :has() on scroll-animated or frequently mutated subtrees.

One missing diagnostic detail that changes the recommendation: the exact selector pattern you use in production and the minimum Firefox version you must support. If Firefox is required and :has() is not confirmed stable in that release, the safe path is class-based fallback generated by JavaScript rather than relying on @supports alone.