invokers: Behaviour when interesttarget and invoketarget point to the same element

[lukewarlow]

This isn't something I envisage happening often but as it's possible it's worth making clear. What's the behaviour for when you have both invoke and interest pointed at the same element.

<button invoketarget="popover" interesttarget="popover">Double Target Button</button>
<div popover>Content</div>

Specifically what happens if you hover the button and then click it? Should it close the popover?

Currently it's specced to call togglePopover() which would close it.

[lukewarlow]

I've come across menus before where both a click and a focus/hover would trigger the menu. I worry that people might do the above to try and do this and it not necessarily give the UX a user would expect?

This doesn't necessarily need a behaviour change it could probably just be a documentation thing or even just don't mention it and give people dodgy ideas 😅

[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.

[keithamus]

@lukewarlow does the current Chrome impl lose interest as the button is invoked?

[lukewarlow]

The current chrome impl has no concept of lose interest yet.

Though as currently proposed I imagine it would toggle an already open (from hovering the button) popover which would then close it.

[mfreed7]

I don't think we should do anything special here. If you point both of them to the same element, and you hover and then click, you should get two events and two "toggles".

The one thing that would need to be specified is the ordering. I suppose that's automatically provided, since you can't (?) show interest and activate a control at the same time. But I just want to make sure there's not some corner case I'm not thinking of where they can come at the same time.

[css-meeting-bot]

The Open UI Community Group just discussed invokers: Behaviour when interesttarget and invoketarget point to the same element, and agreed to the following:

• RESOLVED: Don't do anything special in this case.

The full IRC log of that discussion

<masonf> q+
<flackr> q+
<brecht_dr> q+
<keithamus> luke: invoketarget+interesttarget on same element. It can behave oddly. Mason raised timing point. We need to figure out what to do with this.
<keithamus> masonf: This is a authoring error. If you've done it you'll fix it. I'm worried if we try to fix it there might be a use case that's desired that we should leave to authors.
<keithamus> masonf: I dont know if theres a case where you can show interest in something and activate at the same time
<keithamus> luke: only situation I can think of is interest on mobile is a click, but probably not what we're going to do. I presume it'll be long press
<masonf> ack masonf
<keithamus> flackr: when you click on mobile we focus before we fire click
<keithamus> masonf: on mobile probably interest would be long press + context menu choice, rather than onclick
<masonf> ack flackr
<keithamus> flackr: I dont think we should try to be smart about this. There's also cases where you have a different invokeaction. It may do different things. interest should always happen before invoking I think? We can figure out if its not the case. We only need interesttarget for something to happen at the point of interest or invok
<keithamus> s/invok/invoke
<masonf> ack brecht
<scotto> q+
<keithamus> brecht_dr: small question. Touch screens if you press the button, you trigger a focus first, then I wonder if you use interest on a long press, then that case both are available it should show on press? Or am I thinking wrong?
<keithamus> flackr: might be a case where focus isn't possible
<keithamus> luke: what's ios behaviour with focus? Webkit focus on button isn't default. What's the case with iOS?
<keithamus> brecht_dr: when you have info icon, the moment you press on mobile you invoke it'll popup right away? This is expected?
<keithamus> masonf: on mobile its a little funny to show right away other than another press. A tooltip to show...
<keithamus> brecht_dr: Example being hover on desktop vs press on mobile. Simple press to get basic information, like an info icon, with a tooltip. Press on mobile in some cases.
<keithamus> masonf: Thats kind of a workaround for the problem this api is trying to solve.
<keithamus> masonf: I click on this to find out what this button does, so now we can remove this pattern to add a long press to see what the actual button does.
<keithamus> flackr: legacy pointer behavior moves the pointer to tap. This is what does for hover/tap. That hover probably triggers interest. That means we'll always show interest before invoke.
<keithamus> luke: it's possible it'll be triggered without us realising. Gain interest is in chrome canary so we can test and see. We might need to prevent it
<keithamus> luke: with this specific one maybe theres not a resolution we need to come to
<keithamus> masonf: +1 touch screen interest needs more research. Not clear for mobile.
<brecht_dr> +1 on needing more research
<keithamus> masonf: a bit orthogonal to this issue.
<keithamus> q?
<masonf> ack scott
<keithamus> scotto: more research is definitely needed. Has anyone been working on this? Google for instance? How this might work on android? I've worked with people who can't touch - they use eye tracking. I know speaking to them long press is not something very easy for them to do. I'm interested how something like that works for someone who can't touch
<keithamus> their touchscreen. Or talkback, or voiceover. Any way to have browser/native app heuristics to show them? Any of those discussions started?
<keithamus> scotto: having it there under long press, people might discover to do that.
<keithamus> luke: my assumption is longpress menu is that talkback has various mechanism to load that menu? I believe that's the case.
<keithamus> luke: you definitely raise a good point. We need to think about AT use case.
<keithamus> q+
<keithamus> luke: one of the reasons interest is interest. Designed to work with all the different mechanisms.
<masonf> q+
<keithamus> flackr: I agree the with the context menu assumption
<masonf> ack keith
<masonf> keithamus: this is where the design is useful. There's a declarative way to point to another element, so that AT can see this relationship and do the right thing.
<masonf> keithamus: for pixels on the screen, there's a visual treatment that this is going to have something else you can do, or you can discover it easily via the mouse.
<masonf> keithamus: for AT, buttons announce themselves as things with context menus. Interesttarget is no different. I would hope that interesttarget affects how ATs annouce the element. It would say "push this button to invoke interest" etc.
<keithamus> masonf: theres a distinction between what we build into browsers and what the spec says. The spec says everyone can show interest in different ways. The intention is that it's possible no matter how. But the problem is figuring out how. We want it to work easily for everyone.
<keithamus> masonf: in chromium I don't think it does anything for mobile
<keithamus> luke: unless there is a way to trigger a focus.
<masonf> q?
<keithamus> masonf: which might be what we need to turn off
<masonf> ack mason
<keithamus> luke: lose interest implementation... there's quite a bit more. Once that's done we can think about it more deeply. Especially because a11y wiring and stuff... we've not done it for invokers let alone interest.
<keithamus> scotto: my main point is the potential reliance on long press might... there are some people that work on these browsers that have more info than I do.
<keithamus> masonf: So should we do anything special where interest+invoke point to the same element?
<keithamus> luke: only thing I think could be useful is a devtools message
<keithamus> masonf: I worry if theres some cool use case that that would only annoy
<keithamus> luke: only different sized screens preventing the event
<brecht_dr> q+
<masonf> keithamus: one use case is preloading content when you show interest, then showing it on invoke.
<masonf> ack brecht
<keithamus> brecht_dr: if we would have a manual popover triggered with interest. What happens when we lose focus? Does it close. It does matter if its invoked by an action unless you dont want it to close from some other...
<keithamus> masonf: default action and action=toggle?
<keithamus> masonf: currently have interestaction. Do we have loseinterestaction?
<keithamus> masonf: interestaction=showpopover loseinterestaction=hidepopover invokeaction=togglepopover
<keithamus> luke: as implemented in chrome if you try it it's weird. Gain interest is implemented but lose isn't, so you hover, it shows, move mouse out it doesnt hide, rehover it closes. Because its togglepopover. If you point interest invoker at open popover and trigger interest, it will close it. Might be backwards.
<keithamus> q+
<keithamus> luke: might be gain you show, lose you hide. Maybe not toggle.
<keithamus> masonf: even that behavior you want to explicitly say what interest action is.
<keithamus> luke: please go raise the issue on openui
<masonf> keithamus: loseinterestaction might be too overloaded. You get enough from the fact that it's a loseinterest event. The interestaction would be maybe togglePopover but it'd have different semantics based on which event is being fired.
<masonf> keithamus: I think this is why we didn't initially have interestaction.
<keithamus> luke: maybe we do just auto and custom? Don't even have togglepopover? It solves the thing where it toggles.
<keithamus> luke: when I impled originally it didn't do that. gain showed, lose hid. We changed it to be toggle. Does make sense given shape.
<keithamus> masonf: I thought we wanted auto to be something you do with the function call. That feels magic as well
<keithamus> luke: maybe what we have is fine and it won't come across the weird case?
<keithamus> masonf: unless they do the whats in the issue
<keithamus> scotto: what is the use case for putting it on the same thing?
<keithamus> luke: no use case just that it's a possibility
<keithamus> scotto: I could see it being the same, a button and navigation to open a subnavigation of links. For people who can use a mouse you want it to show on hover and people on keyboard you'd need to be open close via enter key. That could be one reason why.
<keithamus> scotto: you wouldnt want it on focus because it only wants to be on activation. Never want to auto open sublist of nav on focus. Then you'd have additional links of content to navigate to
<keithamus> luke: wouldn't downarrow be used? if you're using focusgroup?
<brecht_dr> q+
<keithamus> scotto: now you're assuming focusgroup on navigation which we shouldn't do
<masonf> ack keith
<keithamus> flackr: also assuming we want...
<masonf> ack brecht
<keithamus> brecht_dr: in scotto's point, if you want both actions, you want the hover effect of interest but not the focus event?
<flackr> s/also assuming we want.../also assuming we want to open every menu that we're skipping over
<keithamus> scotto: there are a number of cases where you want hover to perform like opening something but focus doesn't. You don't want it to show on focus.
<keithamus> brecht_dr: maybe that could be a resolution on this?
<keithamus> masonf: its an issue... it might be desirable to say interest only means hover or keyboard or vice versa
<keithamus> q+
<keithamus> luke: I dont want to be able to do that declaratively. But then you lose making it work without JS. Pointer events are HID agnostic but they give you the type of pointer. So we could do the same for interest
<keithamus> flackr: do you fire interest again if the device changes?
<keithamus> masonf: why would it change?
<keithamus> flackr: if you add an event handler saying "i only care about hover interest" you focus then you need to activate their interest event.
<keithamus> q+
<masonf> keithamus: I feel strongly that interest is an intentional departure from hover and focus. But it doesn't replace hover and focus. So if a developer wants to do something on hover, the event they want is hover.
<masonf> keithamus: you can choose hover if that's what you want. You can choose interest if you just want to respond to interest type things of all kinds.
<keithamus> flackr: but then we're not allowing developers interested in hover/focus to do so declaratively
<keithamus> masonf: but that feels like a footgun, making the footgun harder and involved is good
<keithamus> luke: discussion about css delays... customising those delays based on input. If we allowed author to do that... could they do something like if its focus make the delay infinity. Then it'd only work on hover.
<keithamus> luke: also discussion on doing something on focus not hover, the inverse of this.
<keithamus> masonf: latest on css delays: rather than specifying numbers, specify short/medium/long. Left to UA to decide what they mean, they can have settings, they can further say a short delay for keyboard focus is different to a pointer.
<keithamus> masonf: on second point, probably interest means interest, if you're looking for hover/focus then you have events for that.
<keithamus> masonf: interest should mean "UA is helping you by telling you how the user is interested no matter how the user has shown that"
<masonf> q?
<masonf> ack keith
<masonf> keithamus: it's been covered. Nothing stops us from adding focustarget and hovertarget. I wouldn't advocate for that, but that's a better way to extend than the other way around. Opens the can of worms like clicktarget.
<keithamus> luke: if there are significant enough use cases where one input modality is preferred over the other then maybe thats room to explore specific declarative versions of those. My gut feeling is that interesttarget is the right thing in most use cases.
<keithamus> masonf: most use cases I've seen are broken where they're mistakenly using hover where they maybe want hover and focus
<keithamus> luke: scotto's use case is one though. You can do it with JS but it's less nice.
<keithamus> masonf: once prototype is finished for interesttarget, maybe explore that. Maybe the UA could know that when you're moving focus along a list you're not actually showing interest.
<keithamus> q+
<keithamus> luke: its up to the UA to fully define what interest is.
<keithamus> luke: once we have prototype we can hand it over to developers to see what they can come up with
<masonf> ack keith
<masonf> keithamus: zooming further out, if there are more complex patterns that need more complex user actions, that's what we're here for. Let's build a menu that does all the menu goodness that works!
<keithamus> luke: similar to what I wanted to raise in whatwg with anchor. If the nested is what we get in meantime, focus on interesttarget, then they dont need that. If we build menu it solves that use case.
<luke> Proposed Resolution: Don't do anything special in this case.
<keithamus> luke: if theres a specific user interaction that requires click or hover we should build a primitive for it.
<keithamus> masonf: feels like a number of new issues that need to be filed. Great discussion though. Do we want to do anything with this one?
<masonf> +1
<keithamus> +1
<luke> RESOLVED: Don't do anything special in this case.
<keithamus> masonf: capture action items. brecht_dr had one
<keithamus> luke: coming up with contexts where specific input modality is exclusive - could be an action item. Carousel, on focus not hover. Menu one - on hover not focus. We could come up with more examples
<keithamus> flackr: carousel is what you'd want in any radio group type use case.
<keithamus> masonf: action item is to built out at least those two? Explore further is the action item?
<keithamus> luke: prototype not that useful at the moment
<keithamus> flackr: opened issue for scroll marker use case which is the carousel one
<masonf> The issue is here: https://github.com//issues/1031
<keithamus> masonf: Out of time, last one for next week!
<keithamus> https://github.com//issues/1036