[invokers] loseinterest should include a "safe area" mechanism

[lukewarlow]

The concept of a safe triangle (or other shape) between the interest Invoker and the invoked element is often implemented by Devs. This is often used to help meet WCAG (https://www.w3.org/WAI/WCAG22/Understanding/content-on-hover-or-focus.html).

We should ensure that interest target is designed in such a way that this concept is either built in by default or trivially enabled.

[lukewarlow]

https://x.com/claviska/status/1729964684441223319?s=20 this is just one example of many that quickly provides a visual demonstration of what I mean.

https://x.com/claviska/status/1710098277767729479?s=20 here is another.

https://twitter.com/diegohaz/status/1735639392369136060?t=sdPF9cS_dMRejRg0d169Tw&s=19 Another example of the safe area mechanism

https://x.com/rauchg/status/1765192388258287768?s=20 another example

[lukewarlow]

https://www.smashingmagazine.com/2023/08/better-context-menus-safe-triangles/ also provides a good explainer

[lukewarlow]

It's possible that a delay mechanism is good enough, so a loseinterest could be delayed by a second and cancelled if interest was regained (cancelled rather than re triggering to avoid unwanted animation) but I'm not convinced it would be.

Requiring a loseinterest delay could lead to user annoyance when they move their mouse in a way that very obviously should dismiss one popover and load another?

The second tweet linked above and the menu case in the linked article are two such examples.

[brechtDR]

It certainly is an interesting concept. Not sure if this is something that we could achieve with CSS anchoring in the future and adding a pseudo element to the tooltip to create the lace. 🤔 Should try this out.

[lukewarlow]

Also should consider if this should be linked to CSS anchor positioning somehow or if the positioning mechanism is tangential to this concept.

What happens if the hover triggers something far away from the invoker? Do we set a max size for the safe area before we don't bother?

[keithamus]

@mfreed7 originally mentioned this here: #905 (comment) and I’m fully on board but we deferred it while the proposal migrated repos and the idea got left on the cutting room floor, so glad you’ve revived it and given it a proper issue.

[mfreed7]

I'm also uncertain about the "safe triangle" behavior - could that be spec'd in a clean way for all possible triggers and targets?

I do think that even if we add the "safe triangle" concept, we still need a developer-controllable delay after which the target gets the loseinterest event. And it needs to be properly counted as time away from either the invoker or the target element. I.e. if the delay is set to 1 second, and you move from the invoker to the target in 0.5 seconds, the counter resets to zero. You need to leave them both for 1 second for the loseinterest to fire. If the "safe triangle" is added, staying inside the triangle would similarly reset the counter.

[lukewarlow]

So thinking on the safe area Vs delay thing a bit more, delaying (or not firing) lose interest doesn't actually achieve much in the case where another interest Invoker is nearby. Because chances are a new popover will show which will dismiss the existing one.

It would need to be a delay on triggering a loseinterest AND the following interest event.

[mfreed7]

So thinking on the safe area Vs delay thing a bit more, delaying (or not firing) lose interest doesn't actually achieve much in the case where another interest Invoker is nearby. Because chances are a new popover will show which will dismiss the existing one.

It would need to be a delay on triggering a loseinterest AND the following interest event.

Help me understand this comment. The concept I had in mind is taken from my original proposal for popover. There are two delays - one for the interest event and another for the loseinterest event. But for this example, assume they're both set to 1 second for all invokers. Further assume we're using a mouse, so "hover" is how we get/lose interest. Ok:

1. Hover invoker #1 for 0.5 seconds. (no interest events fired)
2. Hover invoker #2 for 1 second. (invoker #2 fires interest)
3. Hover invoker #1 again for 0.5 seconds. (no events fired)
4. Re-hover invoker #2. (no events fired)
5. Wait 2 seconds. (still no events fired)
6. Hover invoker #1 for 1 second (loseinterest fired for invoker #2, then interest fired for invoker #1)

And as you said, if the delays and actions were set so that an interest on a new invoker fires before the loseinterest on another popover-invoker, then the popover logic will cause the first popover to be dismissed because the new popover is being shown. But that's separate from this proposal.

I think we're in agreement, I just want to make sure.

[lukewarlow]

Ah okay yeah I was thinking just a delay for lose interest not for "gain" interest. Yeah you're right.

[kbrilla]

But delay should not be used for loseintrest on keyboard navigation, or It should be able to configure it separately W dniu pon., 4.12.2023 o 19:36 Luke Warlow ***@***.***> napisał(a):

…

Ah okay yeah I was thinking just a delay for lose interest not for "gain" interest. Yeah you're right. — Reply to this email directly, view it on GitHub <#963 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFKBQQN234I4BRW7WLZJJBLYHYJZXAVCNFSM6AAAAABAAFZKW2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZZGI2DENZTHE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[css-meeting-bot]

The Open UI Community Group just discussed [invokers] loseinterest should include a "safe area" mechanism, and agreed to the following:

• RESOLVED: include developer (and user) control of interest and loseinterest delays. Bring the idea of low/medium/high delays back to CSSWG to get their input.
• RESOLVED: Research across design systems for a "safe area" mechanism for hover triggering.
• RESOLVED: We consider a safe area mechanism for interest triggering to be a good idea and will try to specify what that would look like.

The full IRC log of that discussion

<Zakim> RRSAgent, make logs Public
<RRSAgent> logging to https://www.w3.org/2023/12/14-openui-irc
<RRSAgent> I have made the request, Zakim
<jarhar> lukew: this is something thats come up before, and it came up again so i thought id raise an issue
<jarhar> lukew: theres quite often in design systems people will implement mechanisms so if you have a menu and a submenu, moving from one to the other doesnt close the submenu and mess you up
<dbaron> i/RRSAgent, make logs Public/Topic: [invokers] loseinterest should include a "safe area" mechanism/
<jarhar> lukew: if you dont move fast enough or in the wrong way it doesnt behave as you want
<jarhar> lukew: some idea of a safe area mechanism should be looked into for the interest based triggering for invokers
<jarhar> lukew: whether that happens to be the mechanism they use, shape with your mouse cursor, tiled popover or what
<jarhar> lukew: worth investigating that more than just having a delay
<masonf> q+
<keithamus> q+
<jarhar> masonf: my sense is - i like this idea, i have a couple concerns
<jarhar> masonf: there are a number of ways thats implemented in the wild and we have to pick one
<jarhar> masonf: i think its required to have control over the delays
<jarhar> masonf: the interest event delay - focus it and wait an amount of time. second one when you dehover or defocus
<jarhar> masonf: standard that ive seen in tooltips
<jarhar> masonf: i wonder if theres a phased approach here
<jarhar> masonf: delays are straightforward
<jarhar> masonf: interest triangle might need an opt in if people dont want it
<jarhar> masonf: if its an opt in then we can do it later once we do the first part, we can also see how much its needed at that point
<masonf> ack mason
<jarhar> keithamus: i agree with delays being orthogonal
<masonf> ack keith
<jarhar> keithamus: i agree with them being mandatory
<jarhar> keithamus: i like the idea of safe triangles, its a common ui practice
<jarhar> keithamus: this is kind of a hope of mine, with getting the interest concept decoupled from focus. we can consider more ui afforances like this
<jarhar> keithamus: i think safe triangles is the common practice
<jarhar> masonf: do you agree with it being optional?
<jarhar> keithamus: i dont think necessarily it should be optional. i think the spec should just make a suggestion that user agents are able to do this
<jarhar> keithamus: there should be some kind of flexibility in how its implemented
<jarhar> masonf: the reason i brought up optionality is that we are all thinking of the normal use case - click a button get a menu next to it. this is a general api for i am interested in this thing. what if you have a button in one side of the page and popover is in the other and triangle is now huge
<jarhar> keithamus: thats where i see additional heuristics being applied in the UA that we can trivially specify in the spec
<jarhar> keithamus: where the UA can draw this theoretical triangle and reason about how much of the screen it covers or distance between elements
<jarhar> keithamus: not exclusive for menus. ensuring that someone can move their cursor between the elements. could be tooltips
<masonf> q+
<lukew> q+
<jarhar> keithamus: if you have a large tooltip like a github hovercard, i dont think it would be necessarily - it wouldnt occlude too much of the page. if youre traversing in that direction then you should be able to move your cursor there
<jarhar> keithamus: other than the edge case of things being far apart, i dont think theres going to be many problems
<jarhar> keithamus: i do acknowledge that - there should be some kind of prose in the spec that says UAs can do what they want in this regard
<jarhar> dbaron: im a little worried about making stuff like this too UA dependent. what happens in this situation is that pages depend on the behavior of a UA with large market share and then the other UAs have to copy that
<jarhar> dbaron: better to specify the sort of behavior that UAs are going to have to copy from each other anyway, its going to end up being one thing anyway, might as well figure it out
<masonf> ack dbaron
<jarhar> masonf: similarish comment. thats a key thing. in my head i guess there are - we have talked about other ways to show interest on non-mouse platforms, eye tracking
<jarhar> masonf: necessarily other modes of input will have to depend on a UA to figure out what interest is
<jarhar> masonf: mouse needs to be more carefully locked down
<jarhar> masonf: one example of this - explicitly put controllable delays - one of the big complains about the built in tooltips with title attribute is that the delay is wrong
<keithamus> q+
<jarhar> masonf: all this behavior is that this UA behavior is annoying and we need to provide more control over it
<masonf> ack luke
<jarhar> masonf: the safe triangle, idk i think i might be honing in too much on the delays. if we had the delays carefully controlled, heuristics are up to UA, i guess its up to how its written
<jarhar> lukew: i think 3 things. the delays are definitely a must for me. this wouldnt be instead of delays, you can configure those
<jarhar> lukew: title attribute takes forever to show up
<jarhar> lukew: on that note, i think that its possible that youd want to delay of the lose interest event to be very low
<jarhar> lukew: the way in which you can move between them would be a safe area
<jarhar> lukew: safe area would be part of the trigger target
<jarhar> lukew: you mentioned in the issue if you hover the trigger it - safe triangle would effectively be part of that
<jarhar> lukew: ive seen implementations of that simplified, but i dont think it would be impossible to specify
<masonf> q?
<jarhar> lukew: you could come up with heres your popover, get the bounding box, do some maths to create a shape based on mouse cursor position, and we could specify that
<jarhar> lukew: it would need specifying for the reason that browsers might not implement it or all implement it the same way so might as well spec it
<jarhar> lukew: if its not specified then people might make their own system anyway just in case
<masonf> q+
<jarhar> lukew: it would be interest for hover specifically, focus doesnt need safe area
<jarhar> lukew: other mechanisms might, but eye tracking - that wouldnt be exposed, could behave differently anyway
<jarhar> lukew: i think the delays are very important, should be specified if we do it
<jarhar> lukew: like the idea of it being opt in or opt out
<scotto_> +q
<jarhar> lukew: mechanism to say heres the behavior - there are cases where you dont want the safe triangle
<jarhar> lukew: it would be some way to meet wcag requirements
<jarhar> q+ scotto_
<jarhar> lukew: you may have it so if you have a menu with a dropdown, theres not a delay between that and triggering the next one
<jarhar> lukew: thats where it could be separate from the delay
<jarhar> lukew: safe area would allow you to have a safer ux
<masonf> ack keith
<jarhar> keithamus: in macos native menus and in kde native menus, they have safe triangles. vs code also implements
<jarhar> keithamus: typically it follows the cursor - two points are touching the new floating element and third tracks the cursor. moving directly downwards invalidates the triangle
<jarhar> keithamus: move towards the floating element does not remove the element even if you deviate slightly. a move straight down will lose interest in that element
<jarhar> keithamus: delays are very configurable. should be because people like to configure delays
<jarhar> keithamus: counterpoint exists for safe triangles. people implement this pattern where it doesnt exist, but people arent looking to customize it
<jarhar> keithamus: very sublte variations but generally all the same
<jarhar> keithamus: looking at kde, if im inside the safe triangle area, but hover states for menu items below will activate
<jarhar> keithamus: i can hover over a menu item below the submenu, and it highlights in blue even though other menu is open
<jarhar> keithamus: click events will also act on the submenu items. kind of just works and feels nice
<jarhar> masonf: all good points. im advocating for two delays, and you said people might want the lose interest to be very low and rely on the safe triangle. might be ax issues with that, you might need the delay because you cant move cursor in a straight line. should there be a third delay for the safe triangle?
<jarhar> keithamus: thats what the safe triangle combats. if you cant move in a straight line, theres that extra affordance area, if youre moving in that general direction it works
<lukew> q+
<jarhar> keithamus: theres no delay for when the safe triangle is no longer active. you can spend minutes moving the mouse towards the new menu item and it will still be active
<jarhar> keithamus: im happy to also consider a delay on that if thats necessary
<jarhar> masonf: just want to make sure we do the right thing
<jarhar> masonf: if triangle is very narrow, you have to follow a straight line
<jarhar> masonf: it sounds like theres a lot of interest in safe triangle and there is roughly one way to do it, so maybe try to define that thing and write it down
<jarhar> masonf: i would like to see the delay questions answered, do we allow delay or not
<jarhar> masonf: theres a whole category of keyboard/focus behavior. how does that interact with these things?
<jarhar> masonf: i proposed these delays to apply to focus as well to give similar feel
<jarhar> masonf: on loseinterest that would do the same thing
<jarhar> masonf: i want to make sure were thinking about that as well
<jarhar> masonf: other input modalities need to be up to the user agent to define
<masonf> ack mason
<jarhar> scotto_: most things have already been said
<masonf> ack scott
<jarhar> scotto_: one thing i did want to mention is the delays
<jarhar> scotto_: particularly mouse vs keyboard
<jarhar> scotto_: arguably you would want to be able to define those separately
<jarhar> scotto_: for keyboard users, if there is a ui full of popups that you dont care about, there can be use cases where this popover just shows a little bit of description, the full version of accessible name, and people dont care about that
<jarhar> scotto_: if those are 3 focus stops in between their target, a slightly longer delay is nice because things arent just flashing
<jarhar> scotto_: counterpoint, maybe theres a popover with interactive element inside it, dont want to miss the fact that you could have tabbed over the popover
<masonf> q+
<jarhar> scotto_: previous exmaple with slight delay, maybe someone hovered over something explicitly, they want to see it right away
<jarhar> scotto_: with mouse hover people might want it to show up quicker
<jarhar> scotto_: keyboard user doesnt have a way to indicate that they just want to move past it
<jarhar> lukew: how much of the control of delays is user control vs author control?
<jarhar> scotto_: its all user
<jarhar> scotto_: author doesnt speak for users, everybody wants something different
<jarhar> lukew: how much of these problems could be solved by UA having user overrides?
<jarhar> lukew: if i as a browser user could say i want keyboard to be like this and mouse to be like this
<masonf> q?
<jarhar> lukew: if you arent very fast on a mouse, set mouse de-interest time to be quite high
<masonf> ack luke
<jarhar> lukew: that could solve some of it
<jarhar> lukew: i think that some of the complexities about configuration is that user will want to change it, idk how much author might in terms of keyboard vs mouse
<jarhar> masonf: thats an interesting idea. generally agree that its mostly user
<jarhar> masonf: but there are also some parts of that which are up to the developer. if youre dragging your mouse down a row of things then you want a fast delay
<jarhar> masonf: maybe instead of specify an actual time value, we give the developer low/medium/high and is up to the UA to define and also have a setting to lengthen those delays
<jarhar> masonf: youve given some control to both groups
<jarhar> masonf: maybe gets around problem of keyboard delays being different
<jarhar> masonf: delay "normal" means something different for keyboard and mouse
<masonf> q
<masonf> q?
<jarhar> masonf: these delays should be css, there is already an open issue about these delays. i wonder if these thoughts should be brought back there
<masonf> ack mason
<jarhar> scotto_: i really like those ideas. that would be interesting
<jarhar> scotto_: every interface is going to want to define their own thing. theyre going to have ideas of what their delays should be like colors and sizes
<jarhar> scotto_: theres already user settings that modify these things, like reader mode
<jarhar> scotto_: allow authors to specify stuff and allow users to override. best thing anyone could hope for
<jarhar> lukew: how much power does the spec have to mandate browser settings?
<jarhar> masonf: zero
<jarhar> lukew: we could put a sternly worded note like please do this
<jarhar> masonf: that we can do, but cant mandate it
<jarhar> masonf: are there any resolutions? i have an action item to go back to csswg and bring these thoughts about low/medium/high and differences in timing back to that
<jarhar> masonf: is that ok? other things to resolve?
<jarhar> lukew: were all in agreement that safe area is a concept that we should look further into
<jarhar> lukew: we could resolve on trying to come up with a concrete spec for what that could look like
<jarhar> keithamus: perhaps some user research would be good for how theyre implemented to look for deviations
<jarhar> lukew: not a bad idea
<jarhar> lukew: do research across design systems
<masonf> Proposed resolution: include developer (and user) control of interest and loseinterest delays. Bring the idea of low/medium/high delays back to CSSWG to get their input.
<lukew> +1
<keithamus> +1
<Zander> +1
<masonf> RESOLVED: include developer (and user) control of interest and loseinterest delays. Bring the idea of low/medium/high delays back to CSSWG to get their input.
<lukew> Proposed Resolution: Research across design systems for a "safe area" mechanism for hover triggering.
<scotto_> +1
<jarhar> ++
<scotto_> +1 again
<keithamus> +1
<lukew> RESOLVED: Research across design systems for a "safe area" mechanism for hover triggering.
<lukew> Proposed Resolution: We consider a safe area mechanism for interest triggering to be a good idea and will try to specify what that would look like.
<keithamus> +1
<lukew> RESOLVED: We consider a safe area mechanism for interest triggering to be a good idea and will try to specify what that would look like.

[mfreed7]

Action item done: w3c/csswg-drafts#9236 (comment)

[lukewarlow]

https://react-spectrum.adobe.com/blog/creating-a-pointer-friendly-submenu-experience.html

[github-actions]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.