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 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. 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 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 desktop142Origin trial desktop first135Origin trial desktop last 137Origin 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 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/ch romium.org/d/msgid/blink-dev/B7F891EB-32FE-48FD-B54B-E452AD 74CC3E%40igalia.com Intent to Experiment: https://groups.google.com/a/ch romium.org/d/msgid/blink-dev/CAM%3DNeDiTCMXnR6D-5XdYiwgV_ FMAKE8VM%2Bq-Pyho9KZqoDpSjQ%40mail.gmail.com Intent to Extend Experiment 1: https://groups.google.com/a/ch romium.org/d/msgid/blink-dev/CAM%3DNeDhZosgitNVTVqQ%3DzznM0 JxiH8d0ZoGBManBaE6ByUJ0%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.
