Intent to Ship: Interest Invokers (the `interestfor` attribute)

[Mason Freed]

Contact emails

mas...@chromium.org, chro...@keithcirkel.co.uk

Explainer

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

Specification

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

https://drafts.csswg.org/css-ui-4/#interest

https://drafts.csswg.org/selectors/#interest-pseudos

Summary

This feature adds an `interestfor` attribute to <button> and <a> elements. This attribute adds "interest" behaviors to the element, such that when the user "shows interest" in the element, actions are triggered on the target element, such as showing a popover. The user agent will handle detecting when the user "shows interest" in the element, via methods such as hovering the element with a mouse, hitting special hotkeys on the keyboard, or long-pressing the element on touchscreens. When interest is shown or lost, an `InterestEvent` will be fired on the target, which have default actions in the case of popovers - showing and hiding the popover.

Blink component

Blink>DOM

Web Feature ID

https://github.com/web-platform-dx/web-features/pull/3275

Search tags

interestfor, invokers

TAG review

https://github.com/w3ctag/design-reviews/issues/1058

TAG review status

Issues addressed

Origin Trial Name

The interesttarget Attribute

Chromium Trial Name

HTMLInterestTargetAttribute

Origin Trial documentation link

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

WebFeature UseCounter name

kInterestTarget

Risks

Interoperability and Compatibility

Note: There are interop issues due to WebKit. WebKit has expressed opposition to supporting the "tooltip" use case, citing the lack of "a consistent and reliable way to get to tooltip-like information [on touchscreen]". This is despite *long-press* being the de-facto standard for exactly that interaction pattern, for at least a decade if not longer. See, for example, UIKit's long-press documentation, the following comment on the standards issue, and a similar comment from a year ago which also did not receive a response by WebKit. In addition, WebKit's opinion states that they are unable to identify an interface mechanism for `interestfor` on spatial computing devices. I've suggested that one option is to mandate a particular behavior for these devices, but that comment was ignored.

Importantly, the TAG review was marked Supportive for this overall API proposal.

Gecko: Defer The comments are generally supportive, but without going so far as to mark the issue with "Support". The general tone is supportive of "option 3", which is the one being pursued, to add an item to the context menu on mobile interfaces.

WebKit: Negative This position is not explicitly marked as negative, but the comments (including in the linked HTML issue) are negative: "We therefore remain opposed to this feature"

Web developers: Strongly positive See the linked comment, for a summary of developer opinions from multiple venues. Developers are highly positive on this feature, recognizing the fact that 94+% of top-50 production sites use some form of hover-triggered UI.

Other signals:

Ergonomics

The `popover=hint` API is a fairly important companion API to this one, providing a way to *not* close other unrelated `popover=auto` popover stacks when a tooltip UX is shown.

Activation

There is a polyfill which can be used to mitigate a lack of browser support. See the explainer's touchscreen section for more detail, but since users need to maintain access to the UA-provided <a> long-press context menu, it isn’t possible for the polyfill to support touchscreen long-press on <a> elements without canceling the context menu. Importantly, however, due to this same limitation, almost no production sites today support touchscreen activation of hovercards on links. So the activation story should be fairly good: no loss of functionality on browsers relying on the polyfill, and an enhanced story on touchscreen for browsers natively supporting the feature.

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

There should not be any WebView risk. It's possible that if WebView apps suppress the context menu, then content that uses `interestfor` will not be available within those apps. However, presumably in such an app, the long press gesture is already being intercepted to provide a tooltip or app-provided menu, and that will continue to function.

Debuggability

None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes: https://wpt.fyi/results/html/semantics/interestfor

Flag name on about://flags

Experimental Web Platform Features

Finch feature name

HTMLInterestForAttribute

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/issues/326681249

Availability expectation

Unknown, due to WebKit objections.

Adoption expectation

With the polyfill, it is my hope that adoption can proceed for some sites before Baseline status. That remains to be seen.

Estimated milestones

Shipping on desktop	142
Origin trial desktop first	135
Origin trial desktop last	137
Origin trial extension 1 end milestone	140
DevTrial on desktop	133
Shipping on Android	142
Origin trial Android first	135
Origin trial Android last	137
DevTrial on Android	133
Shipping on WebView	142
Origin trial WebView first	135
Origin trial WebView last	137

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

Since WebKit is objecting to the feature, the HTML spec PR cannot land. It's possible that in the future, when WebKit reviewers give it a review, they find things that they would like to change. Given all of the opportunities provided to them to give this feedback early, we should be highly reluctant to make such changes. However, they are at least possible. The CSS specs have landed in drafts (https://drafts.csswg.org/css-ui-4/#interest and https://drafts.csswg.org/selectors/#interest-pseudos). Those were the result of active discussions in the CSSWG on multiple occasions, with significant feedback from the participants. So I would consider those to be lower risk of changing.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4530756656562176?gate=6100172066258944

Links to previous Intent discussions

Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/B7F891EB-32FE-48FD-B54B-E452AD74CC3E%40igalia.com

Intent to Experiment: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDiTCMXnR6D-5XdYiwgV_FMAKE8VM%2Bq-Pyho9KZqoDpSjQ%40mail.gmail.com

Intent to Extend Experiment 1: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDhZosgitNVTVqQ%3DzznM0JxiH8d0ZoGBManBaE6ByUJ0%2Bg%40mail.gmail.com

This intent message was generated by Chrome Platform Status.

[Domenic Denicola]

LGTM1.

While it's unfortunate that the path to interop here might take longer than we've hoped, it's very clear from the abundant linked documentation that the team has done everything possible to set this feature up for success, and meet the high bar set by our process. The spec PR has received detailed review; the WPTs are comprehensive; a polyfill is ready; and perhaps most importantly, the API has gathered ~3.5 years worth of broad feedback which has shaped and improved it substantially. In my opinion, there's nothing more we could ask for, from an API owners perspective.

[Yoav Weiss (@Shopify)]

LGTM2

Am I wrong to think that if a future mobile interaction would be a better fit for showing "interest" than long-press, UAs can simply wire it to use this APIs semantics?

 

Importantly, the TAG review was marked Supportive for this overall API proposal.

Gecko: Defer The comments are generally supportive, but without going so far as to mark the issue with "Support". The general tone is supportive of "option 3", which is the one being pursued, to add an item to the context menu on mobile interfaces.

Again, the implemented option feels like a UX decision by the browser and can change over time, right?

(I personally prefer option 2 or even option 4 + extra tap to open the menu, but what do I know..)

 

WebKit: Negative This position is not explicitly marked as negative, but the comments (including in the linked HTML issue) are negative: "We therefore remain opposed to this feature"

Web developers: Strongly positive See the linked comment, for a summary of developer opinions from multiple venues. Developers are highly positive on this feature, recognizing the fact that 94+% of top-50 production sites use some form of hover-triggered UI.

With my Shopify hat on, I can attest to the developer need for this.