- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 18 Dec 2024 17:26:08 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-ui] select:hover and select:active styles`. <details><summary>The full IRC log of that discussion</summary> <noamr> dbaron: the issue came up from customizable select<br> <noamr> dbaron: look at the screen capture in the issue<br> <noamr> dbaron: I believe the issue is showing with the default UA styles for customizable select<br> <noamr> dbaron: whether or not it should be part of the UA styles is separate<br> <noamr> dbaron: regardless of the default UA styles, these would be custom styles people would want to write for customizable select and others<br> <noamr> dbaron: the problem is that :hover and :active are hierarchical<br> <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"<br> <noamr> dbaron: CSS can't distinguish between "the select is being hovered" and "something in the select is being hovered, e.g. a popup"<br> <noamr> dbaron: masonf suggested that we break the hierarchical nature of :hover/:active for the top layer<br> <noamr> dbaron: putting something in the top layer is a strong indication that you probably don't want the hierarchical hover/select behavior<br> <noamr> dbaron: welcome to chime in on how to word it, but less important for the call<br> <noamr> dbaron: I want to get consensus that this is a reasonable direction<br> <JakeA> Seems reasonable<br> <ydaniv> +1<br> <noamr> astearns: just hover and active? Or other hierarchical pseudos?<br> <joshtumath> +1 to making an exception for top-layer<br> <JakeA> focus?<br> <noamr> dbaron: I think it's just :hover and :active? Not sure about :focus-within<br> <noamr> dbaron: Haven't thought deeply about :focus-within, maybe not.<br> <noamr> masonf: makes more sense to keep current behavior for :focus-within<br> <JakeA> q+<br> <dholbert> q+<br> <noamr> fantasai: :focus-within is sometimes used specifically for this, e.g. that the focus is within the popup, so would not change it<br> <noamr> astearns: if we make this change, can we somehow enable the current hierarchical behavior?<br> <miriam> :hover:not(:has(:hover))<br> <noamr> dbaron: you could do it with :has<br> <noamr> dbaron: doable, but the vast majority case here is what we propose<br> <noamr> masonf: +1, it's the most common case<br> <astearns> ack JakeA<br> <noamr> JakeA: would the same happen for JS events related to hover/<br> <ydaniv> q+<br> <noamr> dbaron: I don't think we will currently be proposing this<br> <noamr> dbaron: not proposing DOM event changes<br> <vmpstr> q+<br> <JakeA> q+<br> <noamr> masonf: +1, in CSS this is confusing, but in JS changing bubbling in this way would be confusing<br> <astearns> ack dholbert<br> <noamr> dholbert: one use of :hover is to show which a element would be activated<br> <noamr> dholbert: would that change that behavior?<br> <noamr> dbaron: probably true. It's probably a bad idea to put interactive content inside an A element.<br> <astearns> ack ydaniv<br> <noamr> noamr: recursive interactive elements are against ARIA guideliens<br> <noamr> ydaniv: this is the default behavior for menus, working as we expected. So this would be breaking menus<br> <noamr> dbaron: there is a q of whether menus are in the top layer?<br> <noamr> masonf: It depends on how you construct the DOM tree to build the menu<br> <noamr> masonf: the prev example does do exactly that - you can currently activate a link from within the top layer<br> <noamr> ydaniv: I think people rely on the current hover behavior<br> <noamr> masonf: It's still possible to do that<br> <noamr> masonf: are you saying there might be a compat issue?<br> <noamr> ydaniv: yes<br> <noamr> masonf: need to explore compat<br> <astearns> ack vmpstr<br> <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<br> <kizu> q+<br> <astearns> ack JakeA<br> <noamr> JakeA: perhaps a CSS property that creates a boundary for active/hover etc?<br> <noamr> JakeA: that can be in the UA stylesheet<br> <noamr> q+<br> <masonf> q+<br> <noamr> vmpstr: that would work for my use case<br> <astearns> ack kizu<br> <noamr> kizu: I think a CSS property might be dangerous, we try not to create loops<br> <noamr> kizu: maybe an HTML attribute?<br> <noamr> kizu: like enabling it by default for select and not other elements?<br> <JakeA> good point about the loop. It's always the loop<br> <bramus> scribe+<br> <astearns> ack noamr<br> <bramus> noamr: perhaps we can use overflow for this?<br> <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<br> <bramus> … not going to help people relying on it today, but better than relyigng on top layer<br> <bramus> … not sure<br> <bramus> q+<br> <noamr> dbaron: that might get too many other cases where we want the hierarchical behavior<br> <astearns> ack masonf<br> <noamr> masonf: I really like the idea of a CSS property<br> <noamr> masonf: an attribute can be a lot cleaner<br> <astearns> q+<br> <noamr> vmpstr: should be CSS, because it's pseudo-elements<br> <noamr> dbaron: I think we already have solutions for loops for hover/active<br> <noamr> dbaron: we already break loops for hover/active<br> <noamr> dbaron: as long as we don't also touch other things like focus within<br> <noamr> masonf: how does it break the loop?<br> <noamr> dbaron: we don't have spec definitions/interop, but we break loops. I think we update it only once for refresh cycles<br> <noamr> kizu: in Safari/firefox it doesn't exactly work<br> <noamr> dbaron: hover/active already fully have this problem<br> <astearns> ack bramus<br> <noamr> bramus: would this also apply to regular select, or only customizable select?<br> <bramus> https://codepen.io/bramus/pen/GgKWmVg/6a7fa40ecea75e5f07e423d32cc07a7f<br> <noamr> masonf: the old style select doesn't set hover<br> <noamr> bramus: it does, see demo ^^^<br> <noamr> bramus: they apply in chrome/safari, not firefox<br> <noamr> dbaron: I wouldn't be surprised if it's OS specific as well<br> <noamr> q+<br> <ydaniv> q+<br> <noamr> masonf: one key difference is that you can do interesting things with the options, but not here<br> <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<br> <noamr> astearns: maybe go back to the issue?<br> <astearns> ack noamr<br> <astearns> ack astearns<br> <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.<br> <astearns> ack ydaniv<br> <noamr> ydaniv: contain might put us in a loop? Perhaps a new hover-*/active-* sort of things that don't bubble?<br> <kizu> https://codepen.io/kizu/pen/GgKWEZp — CSS hover loop example, behaves differently in Chrome, Safari, and Firefox (but, well, works)<br> <noamr> astearns: taking back to the issue<br> <noamr> 17:04 <astearns> github-bot, take up https://github.com/w3c/csswg-drafts/issues/9141<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11185#issuecomment-2551891900 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 18 December 2024 17:26:09 UTC