Touchscreen behavior for the interesttarget attribute

[mfreed7]

What is the issue with the HTML Standard?

Some references first:

• The interest invokers explainer's touchscreen section
• The OpenUI discussion thread about touchscreen behavior
• Some quick mockups of what the proposed behavior could look like. (Better ones are coming soon.)

This issue is a narrowed down version of the OpenUI discussion above, to hone in on the right final behavior. Essentially, the explainer lays this out:

For touchscreen users, the widely-adopted standard for “showing interest” in an element is the long-press gesture. For native apps, this is the user-expected shortcut to show context menus and access other actions without explicitly activating the element. (See this comment for more context on this point, from developers.)

On the web... most browsers already overload the long-press gesture to provide additional functionality [such as context menus]. Users often appreciate these additional capabilities, and do not want to lose access to them. Therefore, this proposal provides a way to keep both capabilities: the interesttarget behavior and the existing context menus and behaviors.

To show interest in an element via touchscreen, the user simply long-presses that element. This does not activate (e.g. click) the element, it merely triggers interest in the element. This long press immediately fires the "interest" event, but also shows any context menus that would have shown if the interesttarget attribute were not present. So both things happen together. In the case of a popover target element, the idea is that the hovercard popover shows up in addition to the context menu, so that the user can tap on either of those things.

That's the current direction, coming out of OpenUI discussions. This plan seems to have fairly broad consensus from the developers in OpenUI, who seem happy that it will meet their use case. In particular, that use case has been fairly definitively established as: Showing interest on a touchscreen must be done via long-press, and that long-press must simultaneously provide access to the popover hovercard and the UA-provided context menu. Exactly how that's done is up for debate. The explainer goes into detail about the proposed approach, which shifts around the context menu and exposes a "safe area" in which to render the hovercard.

This issue is to check that with the folks in WHATWG, to see if the proposed approach is workable, or if there are better suggestions for how to meet the use case.

[annevk]

I don't understand how the suggestion works because on iOS when you long press a link the entire screen is taken over.

[mfreed7]

I don't understand how the suggestion works because on iOS when you long press a link the entire screen is taken over.

Right - that's similar to what happens on Android as well. That behavior would need to change for elements that have interesttarget, as described in the explainer.

[annevk]

I don't really see how that would work given what we display today. You'd have to not display the preview or something, which I'm not sure is in the end user's best interest. It also seems rather risky to show both platform and web developer UI side-by-side.