Infinite loop when using `:hover` inside `:has()` condition

[daun]

Hi! I've stumbled upon an issue where the plugin would hang in an infinite loop when using :hover inside a :has condition. Below is a concrete example that triggered the infinite loop. I suspect this might be related to #31 and/or fixed by #32, but I'm not too familiar with the inner workings of this (fantastic!) plugin.

header:has(a:hover),
header:has(a:focus) {
  a {
    color: gray;
  }
  a:hover,
  a:focus {
    color: black;
  }
}

[saulhardman]

Hey @daun, thanks for taking the time to create an issue with a test-case/reproduction. I'm looking into this and other issues right now. A question regarding your example: is header:has(a:hover) valid CSS? I wasn't aware that the :has pseudo-class could itself contain pseudo-classes such as :hover. Regardless, I don't think this code should be causing the package to fail.

[daun]

@saulhardman Sure, nesting pseudo-selectors inside :has is a thing. There's a great article on the official WebKit blog that mentions the following example:

form:has(:focus-visible) div:has(input:not(:focus-visible)) label {}

Which is just crazy! But turns out it's valid 2022+ CSS and pretty neat :)

[cdransf]

I'm encountering this issue as well — specifically with a pattern along the lines of .foo:has(+ .foo:hover) — trying to style the sibling preceding the immediate next sibling that's being hovered.

[bodryi]

Hi! Encountering same issue when using css modules.

.form :global(.react-datepicker__time-list-item:hover) {}

As a workaround, we can move :hover out of :global() selector and it definitely works. But the cause of problem wasn't obvious at all.