- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 04 Jun 2025 16:50:13 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `interest delays in CSS`, and agreed to the following: * `RESOLVED: Define shorthand interest-delay for interest-delay-start + interest-delay-end` * `RESOLVED: add a normal keyword as initial value to match platform conventions` * `RESOLVED: Start with single value, add a note about possibility of needing alternative values for e.g. keyboard/touch` <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: interest delays in CSS<br> <fantasai> github: https://github.com/w3c/csswg-drafts/issues/9236<br> <fantasai> masonf: This relates to the interettarget HTML feature, which is about hover triggering, longpress triggering, etc.<br> <fantasai> masonf: For both mouse and keyboard, there's a need for a delay, between trigger and causing the popover to show<br> <fantasai> masonf: We've discussed a few times before<br> <fantasai> masonf: Current proposal is to have longhands and shorthand<br> <fantasai> masonf: for setting show and hide delays separately<br> <fantasai> masonf: That feels decided, but some open questions<br> <fantasai> masonf: One is naming -- current is interest-target-show-delay<br> <fantasai> masonf: it's kinda long, and maybe needs to be more general than about this attribute<br> <fantasai> masonf: There's also a desire to have different delays for e.g. hover vs focus<br> <fantasai> masonf: most natural way seems to be two values, but that's a question<br> <fantasai> masonf: third one is about defaults<br> <fantasai> masonf: some discussion about wanting show delay to be zero so it's immediate<br> <fantasai> masonf: certainly for debugging it's easier, you can add delay if it's too fast<br> <fantasai> masonf: but for hide, desire to be slower, because you need time to move from target to popover without dismissing the popvoer<br> <fantasai> masonf: also desire for keywords like 'normal' to set values if you don't particularly care<br> <flackr> q+<br> <TabAtkins> q+<br> <astearns> ack flackr<br> <fantasai> masonf: so interested in feedback<br> <smfr> q+<br> <fantasai> flackr: wrt naming, could just consider interest-delay*<br> <fantasai> flackr: could be interest-delay-start / interest-delay-end as longhands<br> <fantasai> flackr: wrt defaults, i'd like to align with platform features that have same intended use case<br> <fantasai> flackr: but maybe that's hard<br> <astearns> ack TabAtkins<br> <fantasai> TabAtkins: Don't have a strong opinion about names<br> <fantasai> TabAtkins: for delays, going with 'normal' and recommend that to match platform conventions<br> <fantasai> TabAtkins: nonzero for exit<br> <fantasai> TabAtkins: Wrt different delays for different modes, could extend in the future<br> <fantasai> TabAtkins: can make those a comma-separated list of category and delay<br> <fantasai> masonf: I agree about different delays being extensible<br> <fantasai> masonf: but what about shorthand, since it has two values<br> <fantasai> TabAtkins: give it a specialty syntax branch for setting all value, and different syntax for comma-separated stuff<br> <astearns> ack smfr<br> <fantasai> smfr: Wanted to bring up matching platform behavior, flackr brought up, it's important<br> <fantasai> smfr: I think people with movement disorders, these delays are very important, so I think we should get accessibility review<br> <fantasai> smfr: we should allow platform settings to impact these values, unsure about details<br> <fantasai> smfr: and I'm concerned about web authors making content inaccessible because they choose values that are too short for some users<br> <fantasai> masonf: +1 to accessibility review<br> <fantasai> masonf: but last one was discussed in list -- even if author has provided specific values, browser would be able to multiply the value or impose a minimum deay<br> <astearns> ack fantasai<br> <kbabbitt> fantasai: for TabAtkins comment about shorthand, the way we combine lists ... if we go with list syntax we would just have both values and comma separator<br> <kbabbitt> ... not a problem re: making a shorthand<br> <kbabbitt> ... re: should we have 2 different values or not - I think we might need to<br> <kbabbitt> ... we should probably ask a11y review folks to answer the question of whether we need that<br> <kbabbitt> ... delays for different types of interactions<br> <kbabbitt> ... for the normal value - I think it seems like there's going to be at least 2 different concepts of normal you'd want to convey<br> <kbabbitt> ... one being I have a popup menu of something which is immediate, and other would be on-hover menu<br> <kbabbitt> ... a tooltip men<br> <kbabbitt> ... a tooltip is not instant and shouldn't be instant<br> <kbabbitt> ... 2 categories: things that should be instant and things that should only come up on a delay<br> <flackr> q+<br> <kbabbitt> ... so we might want 2 different keywords for that purpose<br> <kbabbitt> ... if not more<br> <masonf> q+<br> <astearns> ack flackr<br> <kbabbitt> s/tooltip men/tooltip menu/<br> <fantasai> flackr: unfortunately I think the way we're handling this for touch doesn't match the expectations for instant, e.g. for long-press on touch, that doesn't match the menu case of "i want to access a submenu". Maybe it's a different feature<br> <astearns> q+<br> <fantasai> flackr: The whole interest concept seems to be designed around tooltip case, rather than menu case<br> <kbabbitt> fantasai: in that case initial delay of 0 is not the right thing, right?<br> <fantasai> flackr: I agree? :)<br> <astearns> ack masonf<br> <fantasai> masonf: The menu use case is different... this feature is definitely focused more on hovercards and tooltips, so that's definitely a question<br> <ydaniv> q+<br> <fantasai> masonf: to address a few things I heard, I think normal can pretty easily address fantasai's last comment wrt hovercard vs tooltip<br> <fantasai> masonf: we already have different behavior -- called plain tooltips and rich tooltips<br> <fantasai> masonf: hovercard vs tooltip<br> <fantasai> masonf: we could very easily key off of that, and set delays appropriately<br> <fantasai> masonf: wanted to ask follow-up question -- normal or auto?<br> <TabAtkins> +1 to normal<br> <kbabbitt> fantasai: would probably go with normal assuming this is something you expect to be normal<br> <TabAtkins> this isn't computed based on other styles, which is what we usually use "auto" for<br> <kbabbitt> ... if this is the normal delay, calling it normal makes sense<br> <TabAtkins> normal being "platform defaults" is consistent with our usual usage<br> <fantasai> astearns: I think normal could handle differnet delays depending on context, and then authors have tools to set specific delays if they want something different<br> <astearns> ack astearns<br> <fantasai> +1 TabAtkins<br> <fantasai> ydaniv: agree with flackr wrt ??, but also they usually have non-zero end delays<br> <fantasai> ydaniv: different use case<br> <astearns> s/??/menus/<br> <fantasai> ydaniv: one thing mentioned was keyboard and mouse, not so much mouse as much as hover<br> <fantasai> ydaniv: with touch there's usually expectation for much shorter delays, unless doing longpress<br> <masonf> q+<br> <astearns> ack ydaniv<br> <astearns> ack masonf<br> <fantasai> masonf: The names mouse and keyboard aren't in the name, they're positions in the list<br> <fantasai> masonf: longpress is defined, don't want it to get in the way o fit<br> <fantasai> masonf: Wanted to see if we could get resolutions ...<br> <kbabbitt> s/defined/operating-system defined/<br> <fantasai> masonf: didn't talk much about naming, maybe get resolutions on that and normal default value?<br> <masonf> interest-hide-delay interest-show-delay and interest-delay<br> <fantasai> astearns: interest-show-delay + interest-hide-delay = interest-delay?<br> <kbabbitt> fantasai: normally we have the shorthand be a prefix of the longhand rather than other way around<br> <kbabbitt> masonf: interest-delay-show?<br> <fantasai> fantasai: though it sounds a bit awkward<br> <kbabbitt> flackr: [missed]<br> <fantasai> flackr: interest-delay-start/interest-delay-end<br> <fantasai> RESOLVED: Define shorthand interest-delay for interest-delay-start + interest-delay-end<br> <fantasai> astearns: proposed to add a normal keyword to match platform conventions<br> <fantasai> masonf: what would the spec say?<br> <fantasai> astearns: can we say that it matches normal platform conventions, but has a minimum delay for exit if the platform convention does not?<br> <fantasai> masonf: There are some cases where you want instant<br> <fantasai> astearns: I think we can say it matches platform conventions, but I'd like a little bit of investigation as to what those conventions are<br> <kbabbitt> q+<br> <fantasai> astearns: and if they are configurations by the user<br> <fantasai> astearns: just to know what we're linking up to<br> <astearns> ack kbabbitt<br> <fantasai> kbabbitt: I'm wondering if in appearance:base we want to define consistent values for all UAs, not sure<br> <fantasai> fantasai: I think no<br> <fantasai> masonf: None of the built-in controls have a hover triggered thing<br> <kbabbitt> fantasai: apparance:base is largely about appearance, don't think it should interfere with interaction modes<br> <kbabbitt> ... most people care about it looking the way they want<br> <fantasai> masonf: would agree with that as well<br> <fantasai> kbabbitt: that's fine<br> <fantasai> RESOLVED: add a normal keyword as initial value to match platform conventions<br> <fantasai> masonf: Last question was about whether to have one or multiple delays for different modes<br> <fantasai> astearns: Since we do have an easy extension point, I would prefer to have the single pair of values for now<br> <fantasai> astearns: and then if we determine that's not viable first step, then we can add<br> <fantasai> masonf: I think I agree as well, because in single value we'll get more info on use cases for different modes<br> <astearns> ack fantasai<br> <kbabbitt> fantasai: I think that it's fine to start with spec like this<br> <kbabbitt> ... I think we should do a11y review before we decide it's what we want to settle on<br> <kbabbitt> .. syntax is extensible but if we decide we need 2 categories with different defaults<br> <kbabbitt> ... that's a behavior change we'd need to know about up front<br> <kbabbitt> ... if people think getting existing default is resonable that's fine, if not we need something else<br> <kbabbitt> ... [missed]<br> <kbabbitt> ... but we should definitely get that review and investigation<br> <kbabbitt> ... before we decide this is a good first level<br> <fantasai> astearns: let's add a note to the spec that we're considering have separate settings for e.g. keyboard/touch to make sure that's part of any review that this feature gets<br> <fantasai> PROPOSED: Start with single value, add a note about possibility of needing alternative values for e.g. keyboard/touch<br> <ChrisL> q+<br> <fantasai> RESOLVED: Start with single value, add a note about possibility of needing alternative values for e.g. keyboard/touch<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-2940736593 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 4 June 2025 16:50:14 UTC