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.