[popover] Can we add hover-triggering to anchor (<a>) elements?

[mfreed7]

A common use case for "tooltips" is to show a preview of some content when an anchor tag, e.g. <a href="example.com">, is hovered. That gives users more comfort that when they commit to clicking the link, they'll get what they expect.

It'd be nice to be able to use the declarative hover-triggering feature on anchor tags, and not just on buttons.

Is there any reason not to allow <a popovertarget=foo popovertargetaction=interest> to work, subject to the same limitations and behaviors imposed on buttons?

[YummyBacon5]

Long-pressing on mobile browsers would be an issue, since normally long pressing on links opens a context menu, where the user can copy the link, etc.

But a popover is also supposed to show with the same long-press, so what should happen here? Maybe show the popover first, and once the link is long-pressed again, the context menu shows.

[mfreed7]

Long-pressing on mobile browsers would be an issue, since normally long pressing on links opens a context menu, where the user can copy the link, etc.

But a popover is also supposed to show with the same long-press, so what should happen here? Maybe show the popover first, and once the link is long pressed again, the context menu shows.

Yeah, that's a good question. In my head, it would seem to make sense that if there's a popover trigger on the element, that supersedes the browser-provided context menu, to avoid having both. But that might make people unhappy if the thing they wanted to get to was in the context menu, such as copying the link address. I don't know how to best resolve that. Perhaps your suggestion of the double-long-press is the right answer?

[YummyBacon5]

Another solution could be to have a longer long-press which shows the context menu - in case of the popover covering the original link. And the shorter long-press shows the popover, or to have these the other way around.

But if popovertargetaction=interest is gonna work on as, then I assume all the other popovertargetaction values are not going to work. Which may cause author confusion.

[brechtDR]

I think this is an interesting concept. But i'm not sure if overriding the default behavior of a context menu on mobile is a good idea. It's almost an afordance at the moment that long pressing gives you the ability to copy text. Are we then removing some "default" good user experience?

The longer pressing idea sounds like a solution, but personally I think nobody will have the reflex to press longer than the context menu.

Also, I'm wondering if it is pending on the duration of something being pressed (context, then popover): Could this potentially be an accessibility nightmare for people with (for example) muscle contraction issues?

[css-meeting-bot]

The Open UI Community Group just discussed [popover] Can we add hover-triggering to anchor (`<a>`) elements?, and agreed to the following:

• RESOLUTION: Support "interest"-triggering on anchor elements. Continue thinking about how to expand this to other element types.
• RESOLVED: Support "interest"-triggering on anchor elements. Continue thinking about how to expand this to other element types.

The full IRC log of that discussion

<hdv> masonf: the question is around the behaviour of interest-based triggering can be made to apply to anchored elements
<hdv> masonf: Wikipedia has a nice feature where when you hover over a link it gives you a preview of the page you're going to be taken to
<Luke_W_> q+
<una> q+
<hdv> s/anchored/anchor
<scotto_> q+
<hdv> una: another question that came up: more to anchors than buttons, when interest-triggering means hover with a mouse, focus with a keyboard and long press on mobile. A problem with how this works today is that often mobile browers show a context menu on long press that lets you do things
<hdv> s/una/masonf
<hdv> masonf: and then the third point is we should probably generalise this conversation to other things
<gregwhitworth> ack Luke_W_
<hdv> masonf: that work similarly
<hdv> Luke_W_: Wikipedia is a great example actually of how this works on mobile… it just shows the context menu and doesn't show the popover thingy
<hdv> Luke_W_: of course that would be annoying if people expect this to work and it doesn't
<hdv> Luke_W_: it's balancing user expectations with developer expectations
<hdv> Luke_W_: I wonder if making it not work on mobile in the initial version would be something we could do?
<hdv> Luke_W_: adding interest to anchor generally seems like a good idea
<gregwhitworth> ack una
<Luke_W_> q+
<gregwhitworth> that's a good question
<hdv> una: at Wikipedia, looking at it now, they use anchors because they actually link to other pages …it seems like they add it to elements that happen to be links, but they could be other interactive elements on other sites
<flackr> +1
<hdv> masonf: we did discuss that exact thing… the key thing is whether or not it is focusable and how it would be triggered (eg 'as if it had tabindex on it')
<hdv> una: I like that idea of making it focusable _if_ you add the behaviour to it
<hdv> masonf: is a bit complicated to make work
<gregwhitworth> ack scotto_
<hdv> scotto_: not sure about that idea, not sure how it could be communicated consistently to users
<hdv> scotto_: not sure if iOS still shows alternative text for images on longpress… I think it doesn't happen anymore… I'm saying this because it really seems like this is something we'd need to discuss with iOS/Android folks
<hdv> scotto_: as it seems today we don't really have a definition of how longpress is supposed to work, that we can rely on for specifying this behaviour
<Luke_W_> https://www.w3.org/2023/08/31-openui-minutes.html#:~:text=openui/open%2Dui.-,Invoker%20Buttons%20%2D%20allowing%20popover/dialog%20and%20more%20to%20be%20invoked%20without%20JS,-masonf%3A%20this this is a link to our discussion from last week for the record
<brecht_dr> q+
<hdv> scotto_: my issue is… popover can be 'whatever', so how can the OS know what a long press is suppoed to do?
<flackr> q+
<masonf> q+
<hdv> s/suppoed/supposed
<gregwhitworth> ack Luke_W_
<hdv> Luke_W_: we did have a discussion on this at WHATWG about should. this just be on element and this came up
<hdv> Luke_W_: for now it would probably be worth to say popover should follow interesttarget behaviour, whatever that is
<hdv> Luke_W_: definitely seems like this is something that needs discussion beyond us, as the specifics could cause nightmares if not thought true
<gregwhitworth> ack brecht_dr
<hdv> brecht_dr: before you could also get a contextmenu but also an opened tooltip, I've seen that happen in design systems before… not saying I'm a fan of the behaviour, but it is out there
<hdv> brecht_dr: I don't like the idea of measuring how long something is pressed to actually show popover or contextmenu
<scotto_> q+
<hdv> brecht_dr: for people suffering from muscle contractions etc that would be a bad idea
<gregwhitworth> ack flackr
<hdv> flackr: longpress is hugely overloaded, not just on the web, also on native, it can be drag and drop, contextmenu and a lot more… I don't see an issue with adding another thing, but it needs to be well defined what takes precedence
<gregwhitworth> ack masonf
<gregwhitworth> q+
<hdv> masonf: I'd like to reiterate this shouldn't be specific to popover, this convo is input to the whole topic in general
<hdv> masonf: one way to do it could be… if you long press on something the user agent shows a context menu, and the first option of that context menu would be a button that opens the popover (we'd need to figure what to title it though)
<gregwhitworth> an inverse declarative timeout :P
<hdv> masonf: questions re delay: should you have two different delays for two different things (I don't think so? should authors be able to control how long the delay for a longpress is?
<Luke_W_> q+
<gregwhitworth> ack scotto_
<hdv> scotto_: I wasn't saying it shouldn't be allowed, but that it would need to be very well defined
<hdv> scotto_: the area is so wide  that I don't think anyone can reasonably say that when someone long presses on a popover, it's going to have to do X
<hdv> scotto_: re: long pressing for people with motor disabilities, yes that can be an issue
<hdv> scotto_: popovers can be used across a number of different kinds of components… so it should be well defined so that the user agent can know what a thing is and provide a good UI for it. As otherwise browsers wouldn't know what to do in those cases
<brecht_dr> q+
<gregwhitworth> ack Luke_W_
<hdv> Luke_W_: I think it's a good idea to be able to customise the hover aspect
<hdv> Luke_W_: I imagine that would only apply on hover but not on longpress
<hdv> Luke_W_: I remember someone suggesting longpress duration should be definable by authors
<hdv> Luke_W_: not sure if something like that was ever implementef
<hdv> s/implementef/implemented
<gregwhitworth> ack brecht_dr
<hdv> brecht_dr: so we can change the behaviour when something is longpressed… I wonder: can we prevent the context menu in case there is an interest on an anchor? or is that a very bad idea?
<hdv> flackr: we can but have to decide what the intended operation is
<hdv> flackr: browsers decided to prefer the contextmenu to text selection… so we'd have to decide if this thing we're defining now is more important than a contextmenu
<flackr> +1 just like you can customize double click timing, i think customizing long press timing should be OS configurable
<Luke_W_> interesttarget
<hdv> gregwhitworth: it feels like we're at a proposed resolution that we're ok with adding interest to anchors, but not limited to popover
<hdv> gregwhitworth: with the caveat that we need to define the behaviours very well
<hdv> flackr: agreed, as long as it is consistent and well defined it should be fine
<hdv> masonf: the difference between text selection and contextmenu is usually whether or not the element is focusable… that's also what we're hanging this on
<hdv> flackr: contextmenu is specifically links and images, not focusability
<hdv> masonf: I think I heard support for adding interest to anchors
<masonf> Proposed resolution: Support "interest"-triggering on anchor elements. Continue thinking about how to expand this to other element types.
<Luke_W_> +1
<flackr> +1
<una> SGTM
<hdv> what una says!
<hdv> una: what I am worried about is people adding anchors that aren't semantically anchors, just to their page just to get this behaviour
<masonf> Proposed resolution: If an element would show a context-menu on mobile when long-pressing, an item should be added to that context menu to allow triggering the popover.
<masonf> RESOLUTION: Support "interest"-triggering on anchor elements. Continue thinking about how to expand this to other element types.
<masonf> RESOLVED: Support "interest"-triggering on anchor elements. Continue thinking about how to expand this to other element types.
<gregwhitworth> Error handling: https://docs.google.com/document/d/1Uzk3dj7T0QpmhF1jKz9Cjy0gW1LMXut_2DlNNqzPGJw/edit
<gregwhitworth> TPAC - joint meeting next Thursday
<gregwhitworth> Zakim, end meeting

[josepharhar]

I like mason's idea mentioned in the call that a long press on mobile on an anchor could show the native user-agents context menu with an additional button to trigger the popover in the page.
If wikipedia were to use this for its anchors, I think that would be best.

[lukewarlow]

For the sake of completeness we should support interest triggering on <area> elements too. Probably goes without saying but gonna say it anyway.

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