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.

[mfreed7]

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.

I agree you'd have to not display the page preview, and in its place leave room for the page's (popover) version of that preview. This is why it seems actually better for the user. Take the Github example right on this page. Long-pressing a username on mobile Safari gives a rather large full preview of the page you get if you click that link. It includes login links, lots of extra stuff, and critically is not interactive at all. While I can see a button marked "Follow" in that preview, I can't tap it. If I do tap it, that navigates me to the new page (potentially losing state from the previous page), and then from there I can tap "Follow". But now I need to know to hit Back to get back to where I was before, and hope that bfcache or form preservation keeps whatever I had been doing there. Total interaction: Long press, tap once, tap twice, Back button.

Contrast that with the new experience, with interesttarget: the preview is smaller and more concise, exactly like the one you see on desktop. There is a "follow" button, which is directly interactive, and can be tapped. That closes the context menu (which I didn't need for this interaction) and likely closes the hovercard also. I'm now back to the original page, having never left it. And I accomplished my goal with a single long-press and a single tap. This feels much closer to the desktop experience to me, and much more user friendly. This is also what a majority of developers would prefer, at least from the OpenUI discussions.

It also seems rather risky to show both platform and web developer UI side-by-side.

I initially shared your concern, but we discussed this at some length in OpenUI, with the conclusion being there's no actual risk. Let me know whether that discussion alleviates your concerns also.