[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?