Re: [csswg-drafts] [css-ui] select:hover and select:active styles (#11185)

I want to raise a slightly different question than the one addressed in the demo.  
(`::picker(select):has(:hover)` is currently treated as an invalid selector, but that doesn’t seem problematic to me since `::picker(select):hover` works, [test](https://codepen.io/sb3nder/pen/EaKVdOQ)).

---

### To clarify my question

It seems a bit strange that `html:has(:hover)` doesn’t match when hovering top-level `::picker()` in certain cases.

If `::picker()` itself matches `:active` or `:hover`, and:
- its child elements (not pseudo-elements) do **not**, or  
- `::picker()` has **no child elements**, only pseudo-elements (as might be the case in future base picker implementations),  

**should `html:has(:hover)` always match while hovering a top-level ::picker()?**

Example structure:
```html
<html>
  ...
  <parent>
    ::picker()
  </parent>
  ...
</html>
```

Test: https://codepen.io/sb3nder/pen/EaKVdOQ

---

### Why I’m asking

I’m investigating whether maintaining `:hover` on an element or pseudo-element,
particularly in the context of in-place system pickers and autocomplete,
is a backward-compatibility constraint.
This came up while exploring pointerevent-related bugs and proposals.

**Should `html:hover` or `html:has(:hover)` always match while hovering anywhere on the page, including over "in-place" system pickers?**

Test: https://codepen.io/sb3nder/pen/bNpwZjX

**Note: this behavior is currently unreliable and inconsistent across browsers, e.g., Chrome vs. Firefox, or autocomplete pickers vs. date pickers etc.**

---

### Thinking about legacy use cases

Consider a menu that opens on `:hover` and contains a `<select>`. If the user moves the mouse pointer over the system picker, whether the menu stays open or closes immediately depends on whether `:hover` still matches somewhere.

From an accessibility standpoint, such menus should ideally rely on `:focus` or `:focus-visible` additionally.
And system pickers themselves typically require focus on the associated element to remain open,
so one of :hover or :focus would usually match.

Are there other legacy use cases I'm missing?
Where this behavior (e.g., `html:hover` or `html:has(:hover)` not matching during system picker interaction) could cause regressions or unexpected behavior?

-- 
GitHub Notification of comment by sb3nder
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11185#issuecomment-3538863153 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Sunday, 16 November 2025 15:18:28 UTC