- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 14 Aug 2024 16:41:52 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Add hover/focus/long-press triggering delays to CSS`. <details><summary>The full IRC log of that discussion</summary> <keithamus> masonf: Quick intro. Recent comments makes me think we need to raise the issue generally on if tooltips are worth solving. This issue is around discussing ideas.<br> <masonf> - Explainer: https://open-ui.org/components/interest-invokers.explainer<br> <keithamus> ... related to interest target proposal<br> <keithamus> ... general story: other API called command/commandfor/invokers. Lets you invoke an element based on activating a button. This API is similar but instead of activating it invokes by merely showing interest; e.g. hovering mouse, focus keyboard, long press on touch, etc.<br> <keithamus> ... use case are tooltips, hovering menus, other cases where the user hasn't yet clicked<br> <keithamus> ... I don't think we want to debate the case just yet but we want to discuss the delays involved in this<br> <keithamus> ... tooltips are typically implemented with delays to avoid very noisy UI. That counts as showing interest. The fact the user, for e.g., has stopped the mouse there for a period of time indicates to the UA the user showing interest<br> <flackr> q+<br> <keithamus> ... why in CSS? The delays aren't necessarily semantic, but also are likely applied unilaterally on the page, so perhaps `*` or some other selector. Also prefers-* queries may influence that, e.g. reduced-motion.<br> <astearns> q+<br> <keithamus> ... some users may prefer longer delays, its also a developer specified period of time, some sites - e.g. games - might want shorter or longer time<br> <keithamus> ... there are two things, one is showing interest, the other is _losing_ interest, when you move away and want it to hide<br> <emilio> q+<br> <keithamus> ... where it currently stands is a single property shorthand with two delays, and values are generic, e.g. short/medium/long. This allows varying by OS or modality, e.g. short might be shorter for keyboard than mouse<br> <oriol> present+<br> <keithamus> ... so. Does this belong in CSS? Or should it be elsewhere? Does the approach make sense? Are there better ideas? Most interested in the last.<br> <astearns> ack flackr<br> <TabAtkins> I think this sounds reasonable and I'd like to explore it. Unsure if this is the exact shape, but this space seems useful to me.<br> <keithamus> flackr: as you were talking; one thing that I kept thinking of; should developers be customizing the delay at all? Original use case for delay is that hover shouldn't be instant. But if we don't allow for customizing we can align to platform delay lengths<br> <keithamus> ... hover menus aren't a good UX pattern... Is this something which needs to be customized or is this something which we can have as a UA value<br> <PaulG> q+<br> <keithamus> masonf: I believe there are different usecases eg menu vs tooltip, tooltip might have a longer delay because you want to make sure the user wants to see that thing whereas menus might be snappy<br> <keithamus> ... there is already `title` attribute which users complain is too long<br> <keithamus> flackr: we should change that if the common feedback is the delay is too long<br> <keithamus> masonf: I don't disagree<br> <kizu> q+<br> <keithamus> astearns: different timing for different affordances could be something in HTML. Different built-in timings for that.<br> <kbabbitt> q+<br> <keithamus> q+<br> <keithamus> astearns: Would we need a `never` or some other value that stays shown until you hover over the next one?<br> <keithamus> astearns: Other question; does this belong in CSS or HTML... maybe this is just a javascript feature? In JS you can determine MQ state and change things so it wouldn't necessarily be in CSS<br> <astearns> ack astearns<br> <TabAtkins> I can definitely say that debouncing correctly is much harder than one would think.<br> <TabAtkins> (I'm doing that in JS for Bikeshed.)<br> <astearns> ack emilio<br> <keithamus> masonf: the reason I don't think it should be in JS is it's tricky, debouncing gets interesting, keeping track of various timings. BTW losing interest can happen from both the button and the thing that invoked it, so it can get tricky in JS<br> <keithamus> emilio: this seems doable already in a sense. The same way people are adding entry/exit animations in dialog. Other than that I think the feature without a hardcoded duration makes sense. In theory UAs or something else should invoke this... ??? like invokers. I wanted to clarify that this seems doable with transition behavior discrete and existing<br> <keithamus> infra, but maybe that's wrong?<br> <keithamus> masonf: it's more tricky to do with entry/exit and some things are impossible like losing interest - you lose interest on the combination of losing interest on both button and invoker<br> <RRSAgent> I have made the request to generate https://www.w3.org/2024/08/14-css-minutes.html fantasai<br> <keithamus> emilio: the way I think with :hover and transition, keeps the interest, only if the thing you're popping up is inside of the dom of the anchor... it's a bit tricky and harder, but not impossible<br> <astearns> ack PaulG<br> <keithamus> masonf: you mention hover, that covers mouse users, but not other input users. Like popover, it sounds simple for one modality but gets complex in the details, thats my concern<br> <ydaniv> q+<br> <emilio> masonf: a counterpoint for that would be that you might be interested only in one kind of interest (like hover, but not keyboard focus perhaps?)<br> <emilio> But yeah the general thing seems worth exploring<br> <keithamus> PaulG: always a fan of progressive enhancement. I worry about lack of consensus on tooltip as a pattern, but just to clarify other patterns Ive seen or used, aside from tooltip... hover menus are a thing. Focus works the same way, focus/hover should do the same thing. Touch is the same as a click... my main area to push back on is timing as a token<br> <keithamus> as a specific time<br> <keithamus> ... a lot of people are concerned with specific times, especially wrt satisfying success criteria.<br> <keithamus> ... so I'd say go towards focus/hover pseudos as a way to separate those out rather than token/values. Touch would be separate<br> <keithamus> ... unless we add another pseudo but I don't think it would make a difference<br> <keithamus> ... everything else seems to be answered by the writeup but I'd like to see other use cases. What seems to far afield?<br> <astearns> ack kizu<br> <keithamus> kizu: authors need a way to provide custom duration, in my example let's say a design system already implements this - they already have different values, we have specific values for this. If we introduce this through CSS we'd probably want to match these. We will not have a different experience, users are used to a certain delay. In this case we'd<br> <keithamus> want to use a custom property in CSS and normalise for every use case. Kind of related to what PaulG says, we'd want some way to separate and where we'd want to apply this.<br> <keithamus> ... usually we dont want any delay with focus, immediate feedback. Reason for delay on hover is you can accidentally trigger, e.g. leave an area, return the cursor the tooltip wants to go away. With focus this isn't an issue. RIght now this can be implemented with transitions, but currently not possible with display transition. When transition to<br> <keithamus> none elements lose events, so you cannot have transition on display.<br> <keithamus> ... So I agree we need this property but it should be more author configurable<br> <keithamus> ... e.g. games might want immediate responses.<br> <astearns> ack kbabbitt<br> <keithamus> kbabbitt: I wanted to make the exact same point on games wanting instant response or 0s or something. AIUI the keywords were introduced to give a degree of control, that's an important use case. I wonder if we could do something similar to e.g. forced-colors where we want to force a UA setting to override what the author sets.<br> <fantasai> scribe+<br> <astearns> ack keithamus<br> <fantasai> keithamus: One use case I want to represent, where CSS feels appropriate<br> <fantasai> ... delay might want to be configurable based on presence of an active tooltip<br> <fantasai> ... e.g. if you currently are looking at a tooltip, and are in a mystery menu<br> <fantasai> ... you might want the delay to be shortened on subsequent things<br> <fantasai> ... that is trivially expressable in CSS right now, but much harder in other languages<br> <astearns> ack ydaniv<br> <fantasai> ydaniv: Agree with keith and roman. Anywhere we try to solve in keywords, it always failed.<br> <kizu> +1 to Keith, libs like Tippy have this as an option: https://atomiks.github.io/tippyjs/v6/addons/#singleton<br> <fantasai> ... for example in smooth scrolling, left up to UA, and we tried to migrate to it but it looks different in different browsers so got lots of backlash from users<br> <keithamus> ydaniv: Anywhere we try to solve values with keywords where the UA can chose, it always fails. For example in scrolling. Smooth scrolling is left up to the UA. It looks different, different speed in different browsers, tons of backlash with that<br> <keithamus> ydaniv: I think here it would be good to go with time values. CSS is a good place to put it. We have all the ergonomics. The right declarative place to put it.<br> <emilio> q+<br> <masonf> q?<br> <astearns> ack emilio<br> <PaulG> q+<br> <keithamus> emilio: I wanted to provide a counter point to the keyword. For more user-choice vs author-choice, e.g. scrollbar with has auto vs precise pixel value, otherwise you cannot allow users who need more delay to have more delay. So I disagree on the need for precise time.<br> <keithamus> astearns: one reason we dont have pixel values for scrollbars is because some OSes don't support changing that, that's not the case for these kind of delays<br> <keithamus> ... if there we platform specific delays that were widely used and people relied on, then I could see your point.<br> <keithamus> ... I don't think this is OS specific.<br> <keithamus> emilio: I agree it's not OS specific. It's more about - as a user... I guess you could override with a user stylesheet, but it loses the intent of making it short or long<br> <keithamus> masonf: I had the same concerns but user agents could have a setting like "double all the delays" or clamp them to a range. As long as the UA can override those specified by the developer, as long as there's a mechanism.<br> <dholbert> q+<br> <keithamus> astearns: I'd definitely support allowing UAs to override, but I don't think we should build it around UA preferences.<br> <astearns> ack PaulG<br> <flackr> q+<br> <astearns> ack dholbert<br> <keithamus> PaulG: multiplicative idea for UA setting would be great. WCAG 221 is 10x, so allowing user 10x time to do a task. If this were part of that this would allow people to spend a lot less code on a feature. Great progresssive enhancement and accuracy across user experiences<br> <keithamus> dholbert: specifying exact time; the idea of letting UAs add multipliers... I worry a little that with specifying exact time, developers would coordinate animations with delays which would look cool but would break with UA adjustments.<br> <keithamus> ... it might not work in practice.<br> <astearns> ack flackr<br> <masonf> q+<br> <keithamus> flackr: I wanted to make an argument against complete customisation. Couldn't UAs have a sensible tooltip delay that makes sense. I've heard interesting ideas of how that could work such as subsequent tooltips being instant - this could be something the UA could do in general. The argument for this is that the UA could provide a consistent<br> <keithamus> experience across sites and the OS.<br> <astearns> ack masonf<br> <keithamus> ... this is why scrolling in general isn't customizable. Users aren't surprised that sites don't change scroll<br> <keithamus> masonf: Is the point that we shouldn't allow customisation, or specific numbers?<br> <kizu> q+<br> <keithamus> flackr: unless we have strong reason to believe that UA delays don't work we should have UA determined.<br> <kizu> q- will comment in the issue<br> <kizu> q- to comment in the issue<br> <keithamus> masonf: appreciate the feedback. I think I heard open questions; specific delays might be better than named values. Different delays based on modality, hover vs touch. Focus delay should be zero, but I think there should be a non-zero focus delay for folks tabbing in the document.<br> <keithamus> ... should there be a pseudo class for first tooltip open, etc... I'd love to have more feedback on the issue. Thanks for the discussion<br> <keithamus> astearns: Is this going to form controls task force, or just tooltip discussion?<br> <keithamus> masonf: I opened this issue about a year ago, but it's clear I need to bring the tooltip issue to the task force as there are wider questions. I don't know if this rises to that level.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9236#issuecomment-2289285305 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 14 August 2024 16:41:53 UTC