The interesttarget attribute/proposal

[mfreed7]

What is the issue with the HTML Standard?

I'm opening this issue to start the conversation about the interesttarget attribute/proposal in WHATWG. This is something we've been discussing for some time at OpenUI, and the explainer is located here:

• https://open-ui.org/components/interest-invokers.explainer

As a quick summary, this proposal (interesttarget) is very related to #9625 (and related PR), which discusses the invoketarget attribute and behaviors. The invoketarget attribute API allows buttons to declaratively invoke other elements such as popovers and dialogs when the button is clicked/activated. The interesttarget attribute, on the other hand, allows many element types (including buttons, <a>, and perhaps others) to declaratively invoke other elements when the user merely "shows interest" in those elements. Here, "showing interest" can be done via the mouse by hovering the element, via the keyboard by focusing the element, or via other means depending on the browser and input modality. A typical very common use case is invoking a tooltip when the user shows interest in the element the tooltip explains. Many more details can be found in the explainer.

@keithamus @lukewarlow

[tabatkins]

+1 to this! Bikeshedded specs use both "invoke"-style and "interest"-style popups, and the more declarative and accessible we can make those, the better.

In particular, I'm happy to see the events API in the explainer, which'll let me fill the popup on demand with the appropriate markup. A spec can easily have thousands of "interest" popups, and generating them all up-front (either in the static markup, or via JS on initialization) was a significant cost that I had to avoid by switching to purely on-demand DOM generation. It'll also simplify the interaction a bit, since I can just reuse a single popup element and won't have to uniquify IDs for all of them.

[annevk]

How does this work on mobile? There sometimes hover is simulated by a single tap and click is a subsequent tap.

Also, I somewhat doubt this can be truly input-agnostic as web developers are often quite particular about the kind of UX they want. It probably has to match to some extent across platforms as otherwise there would be no way to explain this to end users.

[keithamus]

We have an open issue regarding touch inputs (openui/open-ui#1052). Right now we've resolved to make touch inputs implementation defined as there is a lack of cohesive UX across mobile platforms, but we're happy to define something if you think there is a tenable path to doing so.

[othermaciej]

The reason the mobile issue is relevant is b/c that affects whether this should have a name that's explicitly about hover, or a name like "interest" that suggests it is independent of input modality.

On platforms where the primary pointer input is touch or gaze, there isn't an obvious good choice of "interest" user action.

• Touch: need to either not support "interest", or do "tap once for interest, twice to click", which is annoying and may not be what site authors want.
• Gaze (like the gaze-pinch system on Apple Vision Pro): gaze is an indicator of interest, but for privacy reasons can't expose any observable side effects to the page.
• XR Hand input: while in theory it's possible and not a privacy problem to to support hover as the user holding their hand near a point in a page but not quite touching it, that action is tiring and bad ergonomics.

Because of this, I think "hovertarget" is a better name than "interesttarget", because de facto it is tied to hover specifically, and does not actually represent an abstract idea independent of input modality.

Secondarily, it might be good to have advice on whether "interest" should be ignored or should get "simulated hover on first tap" behavior when using touch input, since it will make a big difference to authors which it is and they may affect how/whether they use this attribute. Other specs in the web platform explicitly or implicitly acknowledge the existence of touch input so I don't think it's wrong to address this case. Failing to do so is just biasing things towards platforms with mouse/trackpad input. We should not assume those are the norm and everything else is implementation defined IMO.

[lukewarlow]

Fwiw this would also trigger for keyboard focus as currently proposed, so isn't just - hover on "desktop" platforms.

[mfreed7]

I think it's very worthwhile for folks to read the comments and discussion on openui/open-ui#1052, since it's exactly about this question. The TL;DR opinion there is that for keyboard and mouse, the exact behaviors that define "showing interest" should be standardized. For other input modalities (touch, gaze, future-thing) the spec should say that UA's must allow all users to "show interest", while not specifically defining how to do it. The last thing is very important, or you get the problems that are the primary reason we need this API today: developers implement the behavior for the kinds of input modalities they have, and leave out users. E.g. most tooltips on the web today don't work very well for touch users. We'd like to use this API to fix that situation.

Because of this, I think "hovertarget" is a better name than "interesttarget", because de facto it is tied to hover specifically, and does not actually represent an abstract idea independent of input modality.

As mentioned above, keyboard should be explicitly supported, which is why we didn't want to call it "hover". Also the stuff above, where all users should be able to show interest in something, not just those with a mouse or keyboard.

Other specs in the web platform explicitly or implicitly acknowledge the existence of touch input so I don't think it's wrong to address this case. Failing to do so is just biasing things towards platforms with mouse/trackpad input. We should not assume those are the norm and everything else is implementation defined IMO.

I think our preference would definitely be to standardize how to "show interest" using touch. But it's hard because that's a very platform and browser specific thing today. For example, Apple platforms previously had "force touch". Those have since moved on to "long press", but I'd guess it would have been unfortunate to standardize "showing interest" to be some length of long press, while ignoring what force touch users should be doing.

[domenic]

The spec should say that UA's must allow all users to "show interest", while not specifically defining how to do it

How is Chromium planning to do this on Android?

[mfreed7]

The spec should say that UA's must allow all users to "show interest", while not specifically defining how to do it

How is Chromium planning to do this on Android?

Excellent question, and I don't think we've got a great answer yet. In my opinion, the best I've heard is to add an item to the top of the long-press context menu that can be used to "show interest". What it says is an open question, since "show interest" probably isn't a great explanation for most users for what that means/does. Another idea is to just not show the context menu if an item has interesttarget, and instead fire the interest event. I suspect that's likely a bad idea because it stops people from using the context menu on that item. Better ideas appreciated.

[annevk]

We'd like to use this API to fix that situation.

I'm sorry, but I don't buy that this is going to fix the problem if we don't have a good story. You end up doing the exact same thing you blame web developers of. Also, web developers will want a particular experience. If the experience is going to be inconsistent or non-existent it's not going to be a feature they can adopt.

[mfreed7]

We'd like to use this API to fix that situation.

I'm sorry, but I don't buy that this is going to fix the problem if we don't have a good story. You end up doing the exact same thing you blame web developers of. Also, web developers will want a particular experience. If the experience is going to be inconsistent or non-existent it's not going to be a feature they can adopt.

Help me understand your comment. Are you saying you'd like to add specific details to the standard for all input modalities? E.g. force touch and eye tracking and whatnot? Or perhaps just writing down the details for mobile/touchscreen and leaving eye tracking out? Are you saying the "interest based triggering" use case isn't valid? Are you saying something else?

I think there are a few key differences between all developers everywhere re-implementing interest-based triggering, and three browser engines implementing it once for everyone. There's clear value in the latter, because everyone gets the benefit. If one browser or platform is missing support for interest triggering, bugs will be filed and hopefully fixed.

As to inconsistency between platforms, that's baked in today. If a developer wants to build a tooltip, they can't address eye tracking users, full stop. They often leave out keyboard users, and very often leave out touch users. On the other hand, with the interesttarget attribute, they would be able to declaratively say what they want, and rely on browsers to allow their users to access that functionality, regardless of input modality.

[mfreed7]

Would WebKit be supportive of defining "showing interest" on mobile/touch platforms to be done via long-press? I.e. the spec would say that a long-press (defined somehow) is the exact mechanism for showing interest. That would preclude showing any context menus on long-press for those elements wearing interesttarget, and it would preclude using other mechanisms such as 3D touch (iOS), touch-based-hover built in to the OS (Android), stylus hover mechanisms, etc. to "show interest".

I think that would at least solve your comment for touchscreens. I'm not sure what to propose for eye tracking or other novel interfaces. If there's a standard/universal way to describe a Vision Pro gesture that "shows interest", I suppose we could see about adding it to the spec also?

[flackr]

It's a pretty common pattern on Android native apps to have "interest" like information behind a long press, avoiding cases where that long press also triggers a context menu. E.g.

Long press on + button in system Clock app:

Long press on magnifying glass in Android Settings:

Long press on lightning icon in Android camera app:

I don't see any reason interest on the web couldn't follow the same pattern. Currently on Android web, only images and links have a default context menu. There's also precedent for adding a shorter timeout to one action over the other. E.g. user long presses, after 300ms it no longer produces a click and the interest is triggered, after 500ms a contextmenu is triggered. Drag and drop on the iOS home screen exhibits this: after a short press the item is picked up for dragging, after a long press the context menu is shown.

It's also worth noting that pressing and holding can already trigger :hover behaviors (without clicking) as the web already has established this for compat reasons: https://jsbin.com/gesupif/edit?html,css,js,output

[mfreed7]

There's also precedent for adding a shorter timeout to one action over the other. E.g. user long presses, after 300ms it no longer produces a click and the interest is triggered, after 500ms a contextmenu is triggered. Drag and drop on the iOS home screen exhibits this: after a short press the item is picked up for dragging, after a long press the context menu is shown.

I wonder whether users can navigate this well - it sounds like they have a 200ms window of time to get the "interest" behavior? This is why I was leaning towards including "interest" in the context menu, so that there's only one delay and users have easy access to both things from one menu. I could also see only showing the "interest" and never showing the context menu, but I'm guessing that'll lead to frustration sometimes.

It's also worth noting that pressing and holding can already trigger :hover behaviors (without clicking) as the web already has established this for compat reasons: https://jsbin.com/gesupif/edit?html,css,js,output

This is true. But I'd like to avoid the "double-menu" situation for interest invokers, since I know that causes user frustration in other contexts at least, such as autocomplete. Here's what I see on iOS:

[YummyBacon5]

user long presses, after 300ms it no longer produces a click and the interest is triggered, after 500ms a contextmenu is triggered

I do like this idea. Although, it may be an issue for users with mobility issues, as it requires them to hold down for longer to get the context menu.

Also, most users are already familair with holding down for a certain amount of time for a context menu to appear, so this could break their consistency. This would also make them uncertain on what to expect with every link.

And an interest target might appear over the link, so the user can't long press to view the context menu.

---

But I'd like to avoid the "double-menu" situation for interest invokers

On Android Chrome and Firefox, at least, both links and buttons' text cannot be direcly selected, they only can be selected when text around them is selected and then dragged over. Does iOS also do this?

[mfreed7]

On Android Chrome and Firefox, at least, both links and buttons' text cannot be direcly selected, they only can be selected when text around them is selected and then dragged over. Does iOS also do this?

On iOS Safari, button text is selectable. (See the screenshot above.) Links are not selectable, and they have a separate "full screen link preview" that shows up if you long-press. That would obviously have to go away or be modified, in the case that the <a> had an interesttarget attribute attached, since the current behavior takes over the screen and would cover any popover launched by the interesttarget.

[flackr]

And an interest target might appear over the link, so the user can't long press to view the context menu.

The context menu would still target to the original element. Touch has implicit capture resulting in all subsequent events targeting the original element (i.e. before the interest target popped up).

[mfreed7]

I happened to be reading the spec for close requests today, which says:

In an implementation-defined (and likely device-specific) manner, a user can send a close request to the user agent. This indicates that the user wishes to close something that is currently being shown on the screen, such as a popover, menu, dialog, picker, or display mode.

Some example close requests are:

The Esc key on desktop platforms.

The back button or gesture on certain mobile platforms such as Android.

Any assistive technology's dismiss gesture, such as iOS VoiceOver's two-finger scrub "z" gesture.

A game controller's canonical "back" button, such as the circle button on a DualShock gamepad.

That seems like a great way to spec something that is very device-specific and needs to be open-ended to allow for innovation on the UI surfaces of devices. My proposal for interesttarget would be to use very similar language, including the non-normative examples list, but with the one change from "a user can send..." to something like "a user must be able to send...".