LGTM2
On Friday, September 19, 2025 at 3:16:37 AM UTC+2 Domenic Denicola wrote:
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
<https://open-ui.org/components/interest-invokers.explainer>
Specification
https://github.com/whatwg/html/pull/11006
<https://github.com/whatwg/html/pull/11006>
https://drafts.csswg.org/css-ui-4/#interest
<https://drafts.csswg.org/css-ui-4/#interest>
https://drafts.csswg.org/selectors/#interest-pseudos
<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
<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
<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
<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.
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
<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.
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
<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.
With my Shopify hat on, I can attest to the developer need for this.
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
<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
<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 desktop142Origin trial desktop first135Origin
trial desktop last137Origin trial extension 1 end
milestone140DevTrial on desktop133Shipping on Android142Origin
trial Android first135Origin trial Android last137DevTrial on
Android133Shipping on WebView142Origin trial WebView
first135Origin trial WebView last137
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
<https://drafts.csswg.org/css-ui-4/#interest>and
https://drafts.csswg.org/selectors/#interest-pseudos
<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
<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
<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
<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
<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/097ddcf4-90b6-4d7d-b608-dba5f95593aan%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/097ddcf4-90b6-4d7d-b608-dba5f95593aan%40chromium.org?utm_medium=email&utm_source=footer>.
