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

> 1. Should this new thing affect Javascript event propagation?  My view (and it sound like the majority view?) is that this new thing should only affect selector matching and _not_ event propagation, which is a different thing from how the selectors are defined, and just "happens" to also use the flat tree.

JS doesn't have the concept of 'hover' or 'active'. It has some related events, like `mouseenter`, but preventing those doesn't impact the CSS concept of 'hover'.

JS does have the concept of 'focus', and preventing that does impact `:focus-within`. However, preventing focus event propagation has no impact on `:focus-within`.

I think the simplest way to describe this feature is: It's a barrier to the propagation of [:hover](https://drafts.csswg.org/selectors/#hover-pseudo), [:active](https://drafts.csswg.org/selectors/#active-pseudo), [:focus-within](https://drafts.csswg.org/selectors/#focus-within-pseudo).

> 2. How does this new feature affect things like `querySelector()`, `matches()`, and `:has()`? I think those seem clear - this new feature affects selector matching, and it should therefore "just work" in the same way via e.g. `.matches(':hover')` as it does in a stylesheet with `:hover {}`.

`select:hover` and `select:is(:hover)` mean "match elements in the `:hover` state that are `select`s". So, if propagation of `:hover` is prevented by a child, and that element or one of its descendants is hovered, `select:hover` and `select:is(:hover)` would not match.

The above is similar to "did the select receive a `mouseenter` event?"

`select:has(:hover)` means roughly "match `select` elements that contain an element that matches `:hover`", so this would bypass any propagation prevention.

The above is similar to "did an element within the select receive a `mouseenter` event?"

> 3. What CSS properties are "in play" for this new feature? This should be contained to just those properties that are defined with "an element also matches :pseudoclass if one of its descendants in the flat tree matches". That sounds like only these three? [`:hover`](https://drafts.csswg.org/selectors/#hover-pseudo), [`:active`](https://drafts.csswg.org/selectors/#active-pseudo), [`:focus-within`](https://drafts.csswg.org/selectors/#focus-within-pseudo). Are there others?

There's [`:target-within`](https://developer.mozilla.org/en-US/docs/Web/CSS/:target-within).

> 4. Should the "containment" of these properties happen via a new CSS property or value, or should it happen at the top layer boundary? I'm personally happy with either solution (those are options 2 and 1, respectively, from [this comment](https://github.com/w3c/csswg-drafts/issues/11185#issuecomment-2551909017)). But option 2 feels like a more general solution to me, which gives the developer more control so they can do the right thing.

Agreed. The top-layer solution might be a good fallback if consensus can't be reached on a general solution.

> > Don't we have precedents for this via modal dialogs / fullscreen? Having a modal dialog open or a fullscreen element turns the rest of the page inert. We might want the same to happen for a `<select>` popup? That'd contain focus and pointer events as well, right?
> 
> I think this would be a big mistake. Popovers are not modal, and therefore don't inert the page. For good reason - they're not intended to behave modally. I.e. while you have a `<select>` picker open, you can happily go hover some other element to get a tooltip to show up. Or click on a button elsewhere on the page, which light-dismisses the picker.

Agreed. I don't think this should be used as an opportunity to change a bunch of long-standing and expected behaviours on the platform.

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


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

Received on Monday, 13 January 2025 09:42:57 UTC