[interest invokers] Consider alternative approaches given WebKit opposition

[lukewarlow]

Given that WebKit is explicitly opposed to interestfor in its current shape (whatwg/html#10309 (comment)) I think its worth a discussion on if there's possible steps forward that can help to unlock some of the benefits of interestfor without needing the full declarative API.

[lukewarlow]

For example, what do current JS solutions to this look like. Can we help the ergonomics of a JS solution where ultimately the decision on what counts as interest is up to the author and so the platform isn't making that decision "premature".

We already did popover=hint as a standalone tool that helps make these kinds of patterns easier. Is there more we can do on the trigger side of things?

[lukewarlow]

To be clear the following is just my personal opinion:

As annoying as it is to potentially not be able to get interestfor after the work that has gone into it. I don't think it'd be good to ship this functionality without explicit buy-in from all browser vendors. Much less having one explicitly opposed.

For better or for worse iOS one of the largest computing platforms does not pratically offer alternatives to WebKit (yet). So if they don't support it and and we'll always need a polyfill then this feature being in the platform doesn't actually provide much value.

[mfreed7]

Given that WebKit is explicitly opposed to interestfor in its current shape

Nothing about their objection actually mentions the shape. It states that it is "premature" because "mobile does not provide a consistent and reliable way to get to tooltip-like information". Essentially they deny the existence of long-press on mobile as a de-facto standard for everything other than web browsers, despite research to the contrary, and a dedicated UIKit API for long press. For this reason, I'm unconvinced there's any change that can be made to the shape of the API that will change their opinion. Or at least none that has been stated out loud.

For better or for worse iOS one of the largest computing platforms does not pratically offer alternatives to WebKit (yet). So if they don't support it and and we'll always need a polyfill then this feature being in the platform doesn't actually provide much value.

The polyfill is actually fairly functional. It doesn't provide touchscreen functionality, because (due to lack of interestfor in the platform) that is impossible to implement on the web today. But otherwise, I think it actually could be a very good path forward for sites that want to use this API even on WebKit browsers that don't natively support it.

[tabatkins]

I strongly agree with Mason in this regard. Apple's publicly stated objection is not to any specific aspect of this, but seemingly to the generic functionality in its entirety, despite phone touchscreens having been in incredibly common use for over a decade and this UX pattern, in particular, being incredibly common across the entire app ecosystem on every mobile OS. The public market has iterated substantially and a "long-press" has been the stable winner for this type of interaction on mobile for a long time now; similarly for "hover" as the winning interaction on mouse-driven devices. There are some new form factors (Anne mentions "spatial UIs", presumably referring to VR/AR devices) that do not yet have widely-established and proven interaction patterns, but the existence of new varieties of UI should not block the enshrinement of existing stable UI patterns.

The particular type of interaction represented by interestfor, in particular, is incredibly difficult to do correctly in all aspects for authors (and, to some extent, literally impossible, as mobile platforms don't necessarily offer websites the ability to intervene in some necessary ways). Despite that, it's also incredibly common. Continuing to leave this to authors to figure out on their own is doing a disservice to users, who will benefit greatly from a standardized, predictable, accessible UX interaction here. We've already improved some aspects of it substantially (such as with popover, anchor positioning, etc), but the complete package is still substantially difficult to put together correctly, as wide experience across the website ecosystem shows.

[sorvell]

I think it makes sense to continue to iterate on the design until some agreement can be reached.

On iOS Safari a long press brings up a command menu. Is this not the case on Android/Chrome? Perhaps on mobile the interestfor behavior could be integrated into the command menu somehow?

Now my personal opinion: please do not ship this with a strong objection from Webkit. The reality is that no one will use it if it doesn't work on Webkit and Apple is unlikely to be swayed by other browsers implementing the feature.

[mfreed7]

I think it makes sense to continue to iterate on the design until some agreement can be reached.

We've been iterating since April 2022. How much more do you think is needed?

On iOS Safari a long press brings up a command menu. Is this not the case on Android/Chrome? Perhaps on mobile the interestfor behavior could be integrated into the command menu somehow?

Long press on a link brings up a context menu on both iOS and Android. The final selected behavior is exactly that: add an item to that context menu.

Now my personal opinion: please do not ship this with a strong objection from Webkit. The reality is that no one will use it if it doesn't work on Webkit and Apple is unlikely to be swayed by other browsers implementing the feature.

Without actionable feedback, I'm afraid that would amount to never shipping this feature. And I'm hopeful that the polyfill can be used for browsers that don't support it.

[lukewarlow]

Can you explain how the polyfill can be used for browsers that don't support it while also not working on iOS at all? I know it can't replicate the exact touch screen behaviour but not supporting any doesn't feel right.

Is it possible that the webkit-touch-callout https://developer.mozilla.org/en-US/docs/Web/CSS/-webkit-touch-callout can be used to control whether we get the interestfor behaviour or the default?

If the polyfill can provide a compelling experience then I don't think it's vital to ship in chromium despite objections. If it can't provide a compelling experience well then it can't be used to cover the lack of WebKit support. Either way I don't personally think that shipping in chromium is a net positive for the web.

I completely understand the frustration especially when as you say it's not actionable feedback. But at the same time if this potentially never even gets added to Firefox let alone Safari I don't think its good to ship. The API shape exists and is ready to go should Apple ever change their mind.

To take from the chrome shipping process. What does success look like if this gets shipped? If people can't make this work on iOS they'll never use it at scale. If this ships but can't support 50% of touch devices the original goal of solving this pattern for touch devices isn't met?

Is this something that chrome on iOS can polyfill to some extent?

[mfreed7]

Can you explain how the polyfill can be used for browsers that don't support it while also not working on iOS at all? I know it can't replicate the exact touch screen behaviour but not supporting any doesn't feel right.

Well again, it's not possible (due to the <a> context menu) to polyfill this behavior for touchscreens. But importantly, due to that same restriction, production sites today also do absolutely nothing for touchscreens. So this will not be a loss of functionality, it'll just be the lack of a gain for touchscreen. On supported browsers, touchscreen will work (a gain). On unsupported browsers, the polyfill will handle all cases except touchscreen (no loss). This seems ok to me?

And all of this neglects the very significant user benefit of a standardized API: the interaction pattern on desktop, for hover and keyboard, will be standardized and functional across sites. That seems to always get lost in the debate over this API, for some reason.

Is it possible that the webkit-touch-callout https://developer.mozilla.org/en-US/docs/Web/CSS/-webkit-touch-callout can be used to control whether we get the interestfor behaviour or the default?

This would allow disabling the context menu on links. That's precisely what interestfor is trying to avoid, because that's bad for users. So I'd be against trying to incorporate that into the polyfill, since it'll break things for users, and likely that means developers won't use it.

If the polyfill can provide a compelling experience then I don't think it's vital to ship in chromium despite objections. If it can't provide a compelling experience well then it can't be used to cover the lack of WebKit support. Either way I don't personally think that shipping in chromium is a net positive for the web.

It's clear (to me at least) that the debate over the importance of this API will not be settled by further discussion, it'll only be settled by observing developer behavior and getting folks to use the new API. And again, the native feature will unlock touchscreen-based interest, which is a win as compared to a polyfill.

I completely understand the frustration especially when as you say it's not actionable feedback. But at the same time if this potentially never even gets added to Firefox let alone Safari I don't think its good to ship. The API shape exists and is ready to go should Apple ever change their mind.

I'm hopeful that this gets shipped in Firefox. Mozilla is supportive of stage 2 for this API. And in stark contrast to WebKit's three-sentence objection, the discussion on the Mozilla standards position has been quite detailed and actionable. As far as I can tell, I've addressed most/all points of that feedback.

To take from the chrome shipping process. What does success look like if this gets shipped? If people can't make this work on iOS they'll never use it at scale. If this ships but can't support 50% of touch devices the original goal of solving this pattern for touch devices isn't met?

Success looks like eventual standardization, once evidence becomes available that the API shape is indeed good. And in the interim, the polyfill.

[sorvell]

I completely understand the frustration especially when as you say it's not actionable feedback.

I do as well.

It's clear (to me at least) that the debate over the importance of this API will not be settled by further discussion

I don't know the full history, but based on the noted very limited response, I think this is still unclear.

Is it worth trying to reach out for a dedicated meeting to review the issue in detail?

Some potential things to clarify and discuss:

• the real pain points not having this is causing, perhaps with some concrete examples.
• make sure it's clear that the feature interacts with the context menu. iOS uses this extensively already.
• (is this true?) there are css ways to detect if the feature is present and provide alternate UI when not (e.g. could possibly be used for spatial computing)

[mfreed7]

It's clear (to me at least) that the debate over the importance of this API will not be settled by further discussion

I don't know the full history, but based on the noted very limited response, I think this is still unclear.

1. We started discussing this API 3.5 years ago.
2. The WebKit standards discussion for the overall API started almost 2 years ago.
3. The WHATWG issue was opened 1.5 years ago.
4. The HTML spec PR was opened 8 months ago.

The "limited response", at least in my reading, hasn't been due to time or opportunity.

Is it worth trying to reach out for a dedicated meeting to review the issue in detail?

There have been many.

Some potential things to clarify and discuss:

• the real pain points not having this is causing, perhaps with some concrete examples.

https://open-ui.org/components/interest-invokers.explainer/#survey-of-use-cases

• make sure it's clear that the feature interacts with the context menu. iOS uses this extensively already.

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

• (is this true?) there are css ways to detect if the feature is present and provide alternate UI when not (e.g. could possibly be used for spatial computing)

@supports selector(:interest-source) {
   ... styles ...
}

[sorvell]

Success looks like eventual standardization, once evidence becomes available that the API shape is indeed good. And in the interim, the polyfill.

I'm concerned that feedback will be limited based on reluctance to use the feature without webkit support.

IMO... the overall problem is not severe enough to warrant what is, again my opinion, the extremely limited value and impact of shipping a feature with concrete opposition.

With the overall goal of advancing the quality of web UX, perhaps other strategies make sense like encouraging outreach by dev rel orgs and attempting to canonicalize good UX via recipes / libraries.