The `interestfor` attribute

[mfreed7]

WebKittens

@annevk, @nt1m

Title of the proposal

The interestfor attribute

URL to the spec

https://github.com/whatwg/html/pull/11006

URL to the spec's repository

https://github.com/whatwg/html

Issue Tracker URL

No response

Explainer URL

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

TAG Design Review URL

No response

Mozilla standards-positions issue URL

https://github.com/mozilla/standards-positions/issues/1181

WebKit Bugzilla URL

No response

Radar URL

No response

Description

See also, https://github.com/whatwg/html/issues/10309, which has reached Stage 1 of the WHATWG.

This is closely related to both the popover=hint feature, the commandfor attribute, and the anchor positioning API. This API (interestfor) is the final piece needed in order to unlock the ability to declaratively build tooltips, hovercards, and menus that are triggered by mouse-hover or keyboard/touchscreen.

I am requesting standards positions early in the process, in the hopes of getting valuable technical input on the shape of this API. The current explainer has the latest plan, but that's evolving rapidly. While there is a very draft spec PR, it doesn't yet contain all of the details, so the explainer should be the source of truth for now. Your input is appreciated now, as critical decisions are being made.

If you'd like to try out a prototype implementation, Chrome Canary with "Experimental Web Platform Features" enabled can be used with this quick demo: https://jsbin.com/cosusih/edit?html,output. Note that touchscreen behaviors have not yet been implemented, and details are again changing rapidly.

[annevk]

https://github.com/WebKit/standards-positions/issues/305#issuecomment-2231000262 onward is still very relevant unfortunately.

[mfreed7]

#305 (comment) onward is still very relevant unfortunately.

Thanks for the quick response here. Please help me understand the specifics of the concern, though. In particular, the critical part of that comment seems to be this (correct?):

However, we currently don't see a good UX for this across the many platforms that the web has to support. Tooltips as we know them on desktop are notably absent on "mobile" platforms and have been for close to two decades.

If that's the concern, we've hopefully alleviated much/all of it via the new (and very detailed) section on exactly what the behavior should look like on touchscreen/mobile. (That came out of a ton of brainstorming and discussion that was triggered by your comment, starting here.) If the "touchscreen" section of the explainer doesn't alleviate your concerns, it'd be super-helpful to understand the specifics of what's still missing, so we can continue to work on it.

[annevk]

Not really, see https://github.com/whatwg/html/issues/11058. (And to be clear, there might be other concerns here too.)

[mfreed7]

Not really, see whatwg/html#11058.

Thanks - I hadn't noticed that comment. I just replied there.

(And to be clear, there might be other concerns here too.)

Ok, makes sense. It'd be good to know what those might be, so we can start working on them.

[foolip]

https://github.com/whatwg/html/issues/10309 now has enough support to advance to stage 2, barring any "strong implementer objections". If the WebKit team does have objections to stage 2, please raise them on that issue within a week.

[annevk]

Thanks, I left a comment at https://github.com/whatwg/html/issues/10309#issuecomment-3266951344.

[lukewarlow]

@annevk given that comment should this position be proposed to mark as opposed?

[annevk]

Thanks Luke for the nudge. Colleagues and I discussed this feature at length. We really appreciate all the effort that went into it and acknowledge it's a popular pattern on desktop websites, but we do not think it meets the high bar for new HTML features.

Our problem with the proposal is that it primarily solves the problem for desktop users using a mouse. This goes against the media independent nature of HTML (see https://www.w3.org/TR/design-principles/#devices-platforms and https://www.w3.org/TR/html-design-principles/#media-independence). On mobile and spatial computing platforms users could still access the information, but it becomes a complex multi-gesture journey rather than something easily discoverable. The context menu is by its nature less discoverable than a mouse gesture. Coupled with having to click the correct item within that menu means that the majority of users will likely not be able to use this feature or have to spend too much effort doing so.

An alternative might be to employ multiple taps, by which the first tap triggers "interestfor", and a subsequent tap the action, but this forces potentially unwanted content upon users and creates an inconsistent interaction model.

We are also not convinced that the accessibility story on desktop is good enough, as if users were to slowly tab-cycle through items, they would be forced to go through all the "popup menus" that end up appearing as well.

Overall, while this pattern is popular with web developers, we are not convinced it can be made to work well for all the web's users. This goes against another well-known principle of HTML development (see https://www.w3.org/TR/design-principles/#priority-of-constituencies and https://www.w3.org/TR/html-design-principles/#priority-of-constituencies). For this and the aforementioned reasons we propose resolving this with "position: oppose" one week from now.

[mfreed7]

@annevk, thanks for the detailed reply!

Our problem with the proposal is that it primarily solves the problem for desktop users using a mouse. This goes against the media independent nature of HTML (see https://www.w3.org/TR/design-principles/#devices-platforms and https://www.w3.org/TR/html-design-principles/#media-independence). On mobile and spatial computing platforms users could still access the information, but it becomes a complex multi-gesture journey rather than something easily discoverable. The context menu is by its nature less discoverable than a mouse gesture. Coupled with having to click the correct item within that menu means that the majority of users will likely not be able to use this feature or have to spend too much effort doing so.

This was discussed at some length in the Mozilla standards position, the OpenUI touchscreen issue, and the explainer’s discussion of “option 6”. While we agree the context menu is less discoverable than a mouse gesture, that’s just a general property of the touchscreen interface, and not something specific to this API. E.g. other native apps (besides web browsers) use the long-press → context menu pattern extensively for things like this. I suspect that this pattern is generally less well known than mouse-hover on a desktop website or native desktop application; however, it is nevertheless quite useful and known to many users. The important point about discoverability is that the gesture (long-press → context menu) is more discoverable if it works the same way on mobile web browsers as it does on mobile native apps. For the folks that already know how to do long-press on the rest of their native apps, it’ll feel natural to do it on a browser app. If we alternatively invent a “mobile web browser only” special gesture, it’ll be extremely hard to discover.

You correctly allude to the popularity of this pattern today (e.g. 94% of production sites use it). Given that this has proven to be such a useful pattern for mouse users, and that just saying "don't use it" seems very likely to fail, how can we make it as usable as possible in other modes? We believe interestfor closes this gap.

One additional side-note here: the title attribute is a part of the platform already. It attempts to solve the more basic tooltip use case, not the full interactive hovercard use case. But on most platforms/browsers, the title tooltip is only rendered when hovered with a mouse. It is not typically accessible via keyboard or touchscreen. One exception seems to be the <img> tag, which on both Safari and Chrome, shows the tooltip within the long-press context menu.

An alternative might be to employ multiple taps, by which the first tap triggers "interestfor", and a subsequent tap the action, but this forces potentially unwanted content upon users and creates an inconsistent interaction model.

This was also discussed in the Mozilla standards position, the OpenUI touchscreen issue, and the explainer’s discussion of “option 4”. We generally agree with your conclusion that this would create an inconsistent interaction model.

We are also not convinced that the accessibility story on desktop is good enough, as if users were to slowly tab-cycle through items, they would be forced to go through all the "popup menus" that end up appearing as well.

We discussed this at length in the OpenUI keyboard issue, the CSSWG/WHATWG/OpenUI task force issue, and the explainer’s section on the “partial interest” behavior. The conclusion (from a number of a11y experts that participated in the discussion) was that while conceptually it sounds better to have a special feature to avoid this annoyance, in practice the special feature is actually the more annoying behavior. Users are already used to seeing popovers show up (sometimes, for sites that actually implement keyboard-triggered hovercards) and they know to hit ESC if they aren’t interested in the popover. This API will hopefully fix some of this experience for users of sites that don’t properly implement ESC to close hovercards, or don’t implement delays before showing hovercards.

Overall, while this pattern is popular with web developers, we are not convinced it can be made to work well for all the web's users. This goes against another well-known principle of HTML development (see https://www.w3.org/TR/design-principles/#priority-of-constituencies and https://www.w3.org/TR/html-design-principles/#priority-of-constituencies). For this and the aforementioned reasons we propose resolving this with "position: oppose" one week from now.

The priority of constituencies just puts users above developers above implementers. I think your point is that developers are currently doing something that leaves out many of their own users, and we agree with that. But as implementers, by ignoring this use case and leaving the status-quo as-is, we would be the guilty ones. There is another design principle, “the web is ... multi-device”, which says "content provided by accessing a URL should yield a thematically consistent experience when someone is accessing it from different devices". Again, the web currently makes that difficult to achieve for the hovercard use case, because it takes extra code to support touchscreen users. In our survey of production sites, none of them support touchscreen users for hovercards, likely for this reason. Because no such built-in API exists, the vast majority of web users have no access to hover-triggered content on the web, if they happen to use a touchscreen, or if they use a keyboard on the ~50% of sites that don’t support keyboard-triggered hovercards. We therefore feel that the multi-device principle is the one that matters most here. And we believe the Interest Invokers API, as currently proposed, provides access to all users of the web, including mobile/touchscreen.

[annevk]

No, implementers don't have an obligation to standardize bad patterns. That just ends up further encouraging their usage, to the detriment of a very large segment of the population. If we had done that in the past, the web would have looked quite different. E.g., we didn't standardize upon tables for layout, even though they were overwhelmingly popular for quite a long time.