[css-ui] select:hover and select:active styles

[josepharhar]

In this issue for customizable select colors, there are proposed UA style rules for select:hover and select:active. However, these rules are also applying when clicking and hovering inside the select's popover.

I think that we should make select:hover and select:active not match when the picker is being hovered or activated.

@nt1m @fantasai

[josepharhar]

@dbaron

[mfreed7]

This is a more general issue, it seems to me, with top layer elements. E.g.

  <button popovertarget=foo>Open Popover
    <div id=foo popover>Popover</div>
  </button>

In this case, hovering/activating the popover will trigger :hover and :active styles on the button itself. That feels weird to me for any top layer element, including dialogs. Perhaps we should just add a bit to the spec that hovering or activating top layer elements don't trigger those styles on containing elements? That would feel like a good fix - I don't know of any good use cases for this. And if there are any, they could still be achieved like

button:has([popover]:hover) { /* hover styles for button */ }

[mfreed7]

Side note: this is peripherally related to whatwg/html#10770, which is also about nesting popovers inside buttons.

[mfreed7]

Agenda+ to discuss exempting top layer elements from :hover's and :active's "descendants in the flat tree" clause.

The current spec for :hover says:

An element also matches :hover if one of its descendants in the flat tree (including non-element nodes, such as text nodes) matches the above conditions.

The spec for :active says:

An element also matches :active if one of its descendants in the flat tree (including non-element nodes, such as text nodes) matches the above conditions.

I propose, for both, to change to:

...if one of its descendants in the flat tree (including non-element nodes, such as text nodes) matches the above conditions, as long as the element and its descendant have the same ancestor element within the top layer, or neither the element nor its descendant are descendants of any element in the top layer.

...or similar.

[dbaron]

I was tempted to suggest a rewording like:

An element E also matches :hover if one of its descendants D in the flat tree (including non-element nodes, such as text nodes) matches the above conditions, and both D and E are in the same top layer.

to fix both the case where the descendant itself is an element in the top layer, and the case where the element is in the top layer but the descendant is nested within another element in the top layer... but then I realized that it's still not right because the "top layer root" of an element is an ancestor of that element, not an ancestor-or-self. (Though maybe that's a mistake?) Also, the definitions (unnecessarily) apply only to elements and not to nodes.

so instead, how about a rewording as:

An element E also matches :hover if one of its descendants D in the flat tree (including non-element nodes, such as text nodes) matches the above conditions, and neither D, nor any of D's flat tree ancestors that are flat tree descendants of E, is in the top layer.

[dbaron]

One other note: I don't think this makes :hover any more cyclic than :hover already is. We already have a mechanism for breaking those cycles (for example, when :hover styles change layout in a way that changes whether the element is under the mouse pointer). That mechanism may not be clearly defined, but it exists.

[mfreed7]

After a decent amount of private back and forth with @dbaron, I think I agree with the proposed wording. Perhaps it was only me that missed a few things, but just in case, here are some notes:

An element E also matches :hover if one of its descendants D in the flat tree (including non-element nodes, such as text nodes) matches the above conditions,

Same wording as existing spec, but with D and E defined.

and neither D, nor any of D's flat tree ancestors that are flat tree descendants of E, is in the top layer.

• An element is "in the top layer" if it is one of the elements in the top layer set. Note that a descendant of a top layer element is therefore not automatically "in the top layer", unless it is separately placed there (e.g. nested popovers).
• "top layer root" is defined, perhaps unfortunately, as a non-inclusive ancestor that is in the top layer. So each of the elements in the top layer doesn't have itself as its top layer root. (Note that "ancestor" isn't linked in CSS to a definition, so I'm using DOM's definition of the term.)
• "in the same top layer" means two elements share the same top layer root.
• The above two mean that if E is an element in the top layer, then "E isn't in the same top layer as E".
• @dbaron's proposed wording gets around this by explicitly checking ancestors and descendants to make sure D is contained within the nearest inclusive top layer root.

I think perhaps it might be a better idea to try to fix up at least the non-inclusiveness of "top layer root"?

[css-meeting-bot]

The CSS Working Group just discussed [css-ui] select:hover and select:active styles.

The full IRC log of that discussion

<noamr> dbaron: the issue came up from customizable select
<noamr> dbaron: look at the screen capture in the issue
<noamr> dbaron: I believe the issue is showing with the default UA styles for customizable select
<noamr> dbaron: whether or not it should be part of the UA styles is separate
<noamr> dbaron: regardless of the default UA styles, these would be custom styles people would want to write for customizable select and others
<noamr> dbaron: the problem is that :hover and :active are hierarchical
<noamr> dbaron: where this shows with customizable select, is that if you hover an option in the popup of the select, it makes the customizable select "hover"
<noamr> dbaron: CSS can't distinguish between "the select is being hovered" and "something in the select is being hovered, e.g. a popup"
<noamr> dbaron: masonf suggested that we break the hierarchical nature of :hover/:active for the top layer
<noamr> dbaron: putting something in the top layer is a strong indication that you probably don't want the hierarchical hover/select behavior
<noamr> dbaron: welcome to chime in on how to word it, but less important for the call
<noamr> dbaron: I want to get consensus that this is a reasonable direction
<JakeA> Seems reasonable
<ydaniv> +1
<noamr> astearns: just hover and active? Or other hierarchical pseudos?
<joshtumath> +1 to making an exception for top-layer
<JakeA> focus?
<noamr> dbaron: I think it's just :hover and :active? Not sure about :focus-within
<noamr> dbaron: Haven't thought deeply about :focus-within, maybe not.
<noamr> masonf: makes more sense to keep current behavior for :focus-within
<JakeA> q+
<dholbert> q+
<noamr> fantasai: :focus-within is sometimes used specifically for this, e.g. that the focus is within the popup, so would not change it
<noamr> astearns: if we make this change, can we somehow enable the current hierarchical behavior?
<miriam> :hover:not(:has(:hover))
<noamr> dbaron: you could do it with :has
<noamr> dbaron: doable, but the vast majority case here is what we propose
<noamr> masonf: +1, it's the most common case
<astearns> ack JakeA
<noamr> JakeA: would the same happen for JS events related to hover/
<ydaniv> q+
<noamr> dbaron: I don't think we will currently be proposing this
<noamr> dbaron: not proposing DOM event changes
<vmpstr> q+
<JakeA> q+
<noamr> masonf: +1, in CSS this is confusing, but in JS changing bubbling in this way would be confusing
<astearns> ack dholbert
<noamr> dholbert: one use of :hover is to show which a element would be activated
<noamr> dholbert: would that change that behavior?
<noamr> dbaron: probably true. It's probably a bad idea to put interactive content inside an A element.
<astearns> ack ydaniv
<noamr> noamr: recursive interactive elements are against ARIA guideliens
<noamr> ydaniv: this is the default behavior for menus, working as we expected. So this would be breaking menus
<noamr> dbaron: there is a q of whether menus are in the top layer?
<noamr> masonf: It depends on how you construct the DOM tree to build the menu
<noamr> masonf: the prev example does do exactly that - you can currently activate a link from within the top layer
<noamr> ydaniv: I think people rely on the current hover behavior
<noamr> masonf: It's still possible to do that
<noamr> masonf: are you saying there might be a compat issue?
<noamr> ydaniv: yes
<noamr> masonf: need to explore compat
<astearns> ack vmpstr
<noamr> vmpstr: in carousel scroll-marker/group have the same problem, as when items are hovered the element is hovered. there is no top layer there. perhaps the solution is not about top-layer
<kizu> q+
<astearns> ack JakeA
<noamr> JakeA: perhaps a CSS property that creates a boundary for active/hover etc?
<noamr> JakeA: that can be in the UA stylesheet
<noamr> q+
<masonf> q+
<noamr> vmpstr: that would work for my use case
<astearns> ack kizu
<noamr> kizu: I think a CSS property might be dangerous, we try not to create loops
<noamr> kizu: maybe an HTML attribute?
<noamr> kizu: like enabling it by default for select and not other elements?
<JakeA> good point about the loop. It's always the loop
<bramus> scribe+
<astearns> ack noamr
<bramus> noamr: perhaps we can use overflow for this?
<bramus> … if an el is hovered and has an area outside of its normal overflow and that is hovered, then the element itself is probably not hovered
<bramus> … not going to help people relying on it today, but better than relyigng on top layer
<bramus> … not sure
<bramus> q+
<noamr> dbaron: that might get too many other cases where we want the hierarchical behavior
<astearns> ack masonf
<noamr> masonf: I really like the idea of a CSS property
<noamr> masonf: an attribute can be a lot cleaner
<astearns> q+
<noamr> vmpstr: should be CSS, because it's pseudo-elements
<noamr> dbaron: I think we already have solutions for loops for hover/active
<noamr> dbaron: we already break loops for hover/active
<noamr> dbaron: as long as we don't also touch other things like focus within
<noamr> masonf: how does it break the loop?
<noamr> dbaron: we don't have spec definitions/interop, but we break loops. I think we update it only once for refresh cycles
<noamr> kizu: in Safari/firefox it doesn't exactly work
<noamr> dbaron: hover/active already fully have this problem
<astearns> ack bramus
<noamr> bramus: would this also apply to regular select, or only customizable select?
<bramus> https://codepen.io/bramus/pen/GgKWmVg/6a7fa40ecea75e5f07e423d32cc07a7f
<noamr> masonf: the old style select doesn't set hover
<noamr> bramus: it does, see demo ^^^
<noamr> bramus: they apply in chrome/safari, not firefox
<noamr> dbaron: I wouldn't be surprised if it's OS specific as well
<noamr> q+
<ydaniv> q+
<noamr> masonf: one key difference is that you can do interesting things with the options, but not here
<noamr> astearns: a bit concerned making special case for top-layer when it catches thing that we might not want to catch, and might not work for non-top-layer things
<noamr> astearns: maybe go back to the issue?
<astearns> ack noamr
<astearns> ack astearns
<bramus> noamr: maybe can be another contain? As in “your hover is contained”. perhaps can do something like that. Need to think about it further.
<astearns> ack ydaniv
<noamr> ydaniv: contain might put us in a loop? Perhaps a new hover-*/active-* sort of things that don't bubble?
<kizu> https://codepen.io/kizu/pen/GgKWEZp — CSS hover loop example, behaves differently in Chrome, Safari, and Firefox (but, well, works)
<noamr> astearns: taking back to the issue
<noamr> 17:04 <astearns> github-bot, take up https://github.com//issues/9141

[ydaniv]

Adding what I suggested in the discussion:

Perhaps add a new :hover-*/:active-* that don't bubble? Maybe that would be an easy way out without risking compat issues?

[jakearchibald]

@ydaniv I think the problem is you'd want them to bubble to a point. Otherwise an <img> in an <option> wouldn't trigger hover on the option.

[ydaniv]

@jakearchibald sounds like @scopeing, right? So maybe that should be the place to look for a solution?

[mfreed7]

Thanks for the great ideas in the discussion. It sounds like there are roughly four options on the table:

1. Top layer elements "break" the hover/active "bubbling" behavior (as described)
2. Mint a new CSS property (or new value for e.g. contain) that breaks the hover/active bubbling
3. Mint a new HTML attribute that breaks the hover/active bubbling
4. Create new CSS properties, like :hover-on that don't bubble at all

Briefly listing pros/cons:

Option #1 (break at top layer):

• Pros:
  • Solves for customizable-<select>
  • Likely works as expected in most common cases
• Cons:
  • Might be web compat issues, particularly for nested menus constructed this way today
  • Does not work for non-top-layer use cases

Option #2 (new CSS property):

• Pros:
  • Solves customizable-<select>
  • Works for pseudo elements
  • Does not have web compat issues
• Cons:
  • Might need special care to avoid loops. (:hover/:active already have this issue anyway, so maybe ok)

Option #3 (new HTML attribute):

• Pros:
  • Solves customizable-<select>
  • Does not have web compat issues
• Cons:
  • Does not work for pseudo elements

Option #4 (new, non-bubbling :hover-*, etc):

• Pros:
  • Solves customizable-<select> (with a decently more complicated UA stylesheet)
  • Does not have web compat issues
• Cons:
  • Significantly more difficult to use. E.g. typical desire is for :hover to match all descendants.

[jakearchibald]

Option #3 (new HTML attribute):

• Pros:

  • Solves customizable-<select>

Does it? Aren't you wanting to set the boundary at a pseudo element?

[mfreed7]

Option #3 (new HTML attribute):

• Pros:

  • Solves customizable-<select>

Does it? Aren't you wanting to set the boundary at a pseudo element?

It does - we want to break the boundary at a shadow DOM element (the backing element for ::picker(select)), which we could add an attribute to. But it doesn't solve the carousel pseudo elements use case.

[ydaniv]

Cons:
Significantly more difficult to use. E.g. typical desire is for :hover to match all descendants.

The idea is that it doesn't bubble - as in upwards, so it won't affect ancestors. See demo

The :hover doesn't trickle down, so no issue there.

[dbaron]

I think the problem with option 4 is that you get different div:hover-new behavior for <div>This is text.</div> and for <div>This <span>is text</span>.</div>... you'll fail to get the :hover-new when the pointer is inside the <span>.

And we don't want to solve this by using the div's rectangle, because we actually don't want the hover effect if the popup partially occludes the div and the pointer is in the popup but inside the div's rectangle.

[nt1m]

A slight variation of 4 would be a selector for :hover(in-page) (name to bikeshed) or where descendants are still matched but top-layer descendants excluded.

My preference would be for 1. or what I just described. An opt-in attribute/CSS property would be quite difficult to understand for the majority of cases I think.

[ydaniv]

Another option of scoping 4 could be something like :hover-closest(<selector>) bubbling until first match of <selector>.

[mfreed7]

My preference would be for 1. or what I just described. An opt-in attribute/CSS property would be quite difficult to understand for the majority of cases I think.

select::picker(select) {
  hover-propagation: stop;
}

seems relatively easy to understand, doesn't it? It goes right on the "border" element where bubbling should stop. That's in contrast to the proposed variations for #4 where you have to apply a property to an entire sub-tree, minus a "donut" of that sub-tree.

I'm obviously "ok" with option #1 also, but it doesn't address some of the non-top-layer use cases that were raised in the meeting, like carousel pseudo elements.

[astearns]

For completeness, is there another option to do nothing yet and rely on a more complex :has selector to accomplish the behavior we want in the UA style rules (with the con of forcing authors to use the more complex selector if they want to override things)?

[nt1m]

For completeness, is there another option to do nothing yet and rely on a more complex :has selector to accomplish the behavior we want in the UA style rules (with the con of forcing authors to use the more complex selector if they want to override things)?

Authors will likely want to do this too without some complex :has()/:not() logic.

select::picker(select) {
hover-propagation: stop;
}
seems relatively easy to understand, doesn't it? It goes right on the "border" element where bubbling should stop. That's in contrast to the proposed variations for #4 where you have to apply a property to an entire sub-tree, minus a "donut" of that sub-tree.

I think it raises more questions than answers. A big one is: does it affect JS mouse events? It's not necessarily obvious from the name.

If we were to go this route, maybe something like pointer-events: contain makes more sense? It would end up affecting everything that relates to hit-testing including JS events (like other pointer-events values work)

[jakearchibald]

select::picker(select) {
  hover-propagation: stop;
}

fwiw, I was imagining something like:

select::picker(select) {
  stop-propagation: hover active focus-within;
}

…so you could pick individual things.

does it affect JS mouse events?

Folks in the meeting didn't think it should, and I'm ok with that. However, if folks decide it should impact related JS events, it's important that it only prevents propagation in the bubbling phase. The capturing phase should be left as-is.