Thank you all! Much appreciated. On Fri, Sep 19, 2025 at 7:59 AM Mike Taylor <miketa...@chromium.org> wrote:
> 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? > > You're definitely not wrong. While the keyboard and mouse behaviors would be hard to change in the future without expecting breakage, in my view the touchscreen pattern is likely very easy to change, since it's completely controlled by the UA. I can't see how changing to a different (still-UA-controlled) mechanism would hurt anything. Of course, we can't change back to something like "option 2" <https://open-ui.org/components/interest-invokers.explainer/#option-2---show-both-at-the-same-time> (showing both the context menu and the hovercard), but that was fairly roundly rejected in various places anyway. > > 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..) > > I actually don't think option 2 has legs - it got significant negative reactions from both other implementers. Something like option 4 is still very much in play and something I'd like to see land. But in the form of a new CSS pseudo class, `::interest-button`, as discussed here <https://github.com/w3c/csswg-drafts/issues/12437>. There are still some open standards questions, which is why I'm not including that pseudo with this I2S, but once those are resolved I'd very much like to ship that additional 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. > > Awesome, thanks for providing that feedback. Feel free to reach out to me directly if you have any questions (or find any bugs!) as you try out the API. Thanks, Mason > > 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 > 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 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 blink-dev+unsubscr...@chromium.org. > 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> > . > > -- 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 blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDg5%3Dmzj6nObjYs0K0%2BivAJntv0PgUkNQh6fiJSAWL71hg%40mail.gmail.com.
