Bug 234556 – [:has() pseudo-class] Support for style invalidation with missing interactive pseudo-classes

• Status: NEW
• Component: CSS

[Lea Verou]

:has() does not seem to match when the argument is an interactive pseudo-class (:focus, :checked, :target). 
I’m not sure it's an invalidation issue, because it doesn't apply even when the pseudo-class applies on startup (e.g. a pre-checked checkbox).

Testcase: https://codepen.io/leaverou/pen/KKXvqjG?editors=1100

(Huge thanks to everyone who made :has() happen — what an exciting time!)

[Antti Koivisto]

Thanks for the report.

Of these :focus should be working at least in basic cases. Changing 

.has.focus:has(:checked)

to

.has.focus:has(:focus)

makes that subtest work as expected.

The others are broken though.

[Lea Verou]

Oops! Fixed the testcase, thanks!

[Lea Verou]

Also updated the tests to include :valid, which behaves very oddly:

:has(:valid) seems to match *regardless* of whether a valid control is actually contained within, and said matching doesn't change as descendant controls go from valid to invalid and vice versa.

[Radar WebKit Bug Importer]

<rdar://problem/86763225>

[Antti Koivisto]

Basically we need to use Style::PseudoClassChangeInvalidation around pseudo-class changes for them to invalidate correctly within :has().

[Bill Criswell]

I observed some interesting behavior too. This Sandbox helps explain the situation: https://codesandbox.io/s/silly-gagarin-y0cub

[Antti Koivisto]

(In reply to Bill Criswell from comment #6)
> I observed some interesting behavior too. This Sandbox helps explain the
> situation: https://codesandbox.io/s/silly-gagarin-y0cub

That seems to work fine now after the latest fixes.

[Brandon McConnell]

Created attachment 448043 [details]
screenshot of has pseudo class bug

[Brandon McConnell]

One unexpected side effect I'm seeing so far— it appears that :has sometimes matches for unmatching elements. The inspector doesn't show the styles but they appear on-page.

Example URL: https://codepen.io/brandonmcconnell/pen/45b67ffa16dc41614efdd140bef1f439

Example screenshot attached

[Brandon McConnell]

I have altered my example URL that I linked above to expand on the side effect I noticed. It appears that all three div's, even those that should not be matching are receiving the "has" styles for their own background-color, however, only the correct one receives styles once an additional pseudo-element is specified after the :has pseudo-selector.

[Brandon McConnell]

Created attachment 448044 [details]
screenshot of has pseudo class bug #2

This new screenshot demonstrates the bug, where the "has" styles are visually inherited by elements that do not match the selector, but not their pseudo elements.

[Brandon McConnell]

Upon further investigation, this bug appears to occur during rendering, and if I comment the styles using the inspector and then un-comment then, the styles auto-correct themselves.

I have recorded a Loom video demonstrating this: https://www.loom.com/share/0cf9c18a99a8421f9957ff04c34f64de

This bug is critical to the use of :has() so this should be resolved before the :has() pseudo-class is released into the production browser.

[Lea Verou]

Brandon, could you please file a new bug so its status can be tracked separately?

[Brandon McConnell]

Bill / Lea / Antti — I will open a separate ticket for the concerns I raised.

[Brandon McConnell]

I opened two new tickets to account for the bugs I found:

Bug 234732 - [:has() pseudo-class] Styles matching non-matching elements on load
https://bugs.webkit.org/show_bug.cgi?id=234732

Bug 234733 - [:has() pseudo-class] Not matching elements it should
https://bugs.webkit.org/show_bug.cgi?id=234733

[Adrian]

There's a similar issue with style invalidation when using interactive pseudo-classes (:checked, :focus, :invalid, :user-invalid) with :has within shadow DOM (both imperative and declarative). The styles apply on startup, but are not reapplied on subsequent state changes (e.g. checking and unchecking a checkbox). Test case at https://codepen.io/adini/pen/qBGxydG