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. On Friday, September 19, 2025 at 5:38:28 AM UTC+9 Mason Freed wrote:
> Contact emails > > [email protected], [email protected] > > 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 > <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EDOM%22> > > Web Feature ID > > https://github.com/web-platform-dx/web-features/pull/3275 > > Search tags > > interestfor <https://chromestatus.com/features#tags:interestfor>, invokers > <https://chromestatus.com/features#tags: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 > <https://github.com/whatwg/html/issues/10309#issuecomment-3266951344> 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 > <https://developer.apple.com/documentation/uikit/handling-long-press-gestures>, > > the following comment > <https://github.com/whatwg/html/issues/10309#issuecomment-3267037840> on > the standards issue, and a similar comment > <https://github.com/WebKit/standards-positions/issues/305#issuecomment-2493546945> > > 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 > <https://github.com/WebKit/standards-positions/issues/305#issuecomment-2287429935> > > that one option is to mandate a particular behavior for these devices, but > that comment was ignored. > > > Importantly, the TAG review was marked Supportive > <https://github.com/w3ctag/design-reviews/issues/1058> for this overall > API proposal. > > Gecko: Defer <https://github.com/mozilla/standards-positions/issues/1181> > 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 > <https://github.com/WebKit/standards-positions/issues/464> 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 > <https://github.com/mozilla/standards-positions/issues/1181#issuecomment-3097924236> > > 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+% > <https://docs.google.com/spreadsheets/d/11Bt_FCAqu1hd5llGRGpzgwlgHaqLmOC4SJEMRtNQY-g/edit?gid=0> > > 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 <https://github.com/mfreed7/interestfor> which can be > used to mitigate a lack of browser support. See the explainer's touchscreen > section > <https://open-ui.org/components/interest-invokers.explainer/#touchscreen> 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 > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> > ? > > 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 <https://github.com/mfreed7/interestfor>, 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 > <https://github.com/whatwg/html/pull/11006> 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 > <https://chromestatus.com/>. > > > > > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/65f9cc0e-1f60-4877-b7ad-11970a909937n%40chromium.org.
