Open lukewarlow opened 9 months ago
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
https://www.smashingmagazine.com/2023/08/better-context-menus-safe-triangles/ also provides a good explainer
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.
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.
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?
@mfreed7 originally mentioned this here: https://github.com/openui/open-ui/issues/905#issuecomment-1781167595 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.
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.
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.
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:
interest
events fired)interest
)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.
Ah okay yeah I was thinking just a delay for lose interest not for "gain" interest. Yeah you're right.
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 https://github.com/openui/open-ui/issues/963#issuecomment-1839242739, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFKBQQN234I4BRW7WLZJJBLYHYJZXAVCNFSM6AAAAABAAFZKW2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZZGI2DENZTHE . You are receiving this because you are subscribed to this thread.Message ID: @.***>
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.
Action item done: https://github.com/w3c/csswg-drafts/issues/9236#issuecomment-1856504943
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.