: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!)
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.
Oops! Fixed the testcase, thanks!
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.
<rdar://problem/86763225>
Basically we need to use Style::PseudoClassChangeInvalidation around pseudo-class changes for them to invalidate correctly within :has().
I observed some interesting behavior too. This Sandbox helps explain the situation: https://codesandbox.io/s/silly-gagarin-y0cub
(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.
Created attachment 448043 [details] screenshot of has pseudo class bug
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
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.
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.
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.
Brandon, could you please file a new bug so its status can be tracked separately?
Bill / Lea / Antti — I will open a separate ticket for the concerns I raised.
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
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