Re: [w3ctag/design-reviews] The `interesttarget` attribute (Issue #1058)

mfreed7 left a comment (w3ctag/design-reviews#1058)

> Hi [@mfreed7](https://github.com/mfreed7), and thanks for your review request. We appreciate the use case, and it fits the positive recent trend of bringing widgets into HTML & CSS, and not requiring JS. The opportunity here to improve accessibility sounds good.

Great, thank you for the helpful comments!

> 1. Do you have any data on how widely-requested this feature is by devs? Related, it would help to build up more of a repertoire of use cases. There are at least two on GitHub, which you mention (passively previewing the vital stats of an issue/PR, and previewing a person's info, with the option of following them). However, it would be helpful to collect more; particularly to see if any patterns emerge.

Yes, I’m glad you asked. We actually just updated the explainer to include exactly this set of data. The [expanded introduction](https://open-ui.org/components/interest-invokers.explainer/#the-pitch) includes several interesting bits of data, such as that 94+% of top production websites today use some form of hover-triggering. Perhaps more to your point, there is a new [survey section](https://open-ui.org/components/interest-invokers.explainer/#survey-of-use-cases) that explores many production sites and categorizes their usage into different use cases. It is certainly clear from the data that there are many more interesting use cases than just link previews.

> 2. Regarding alternative approaches: have you considered approaching this problem in a different way - e.g. could it (at least for some use cases) be better addressed by providing a more appropriate preview of the target document, in the case of links having interest targets? Two ways this might be achieved are:
>    
>    * responding to the preview viewport (i.e. having the UA signal that the document is in a preview viewport, and responding to that); and
>    * providing for an alternative document to be given as the preview for a link. (Having a wider review of use cases could help here.)

These are interesting suggestions! I do think these features would improve the “link preview” context menu that is provided on some operating systems today, e.g. iOS. However, I think there are two main problems as it relates to `interesttarget`:
 1. As mentioned in the question above, this only covers a small portion of the target use cases for this API. Hover-triggering is also used for plain or “rich” tooltips, “more info” boxes, and quick action menus, and is used on things that aren’t links, such as `<button>`. Additionally, even for the link preview use case, a key feature is the ability for the user to tap on interactive elements such as a “Follow” button.
 2. Not all operating systems/browsers include a native “link preview” feature.


> 3. [Moderate eagerness](https://developer.chrome.com/blog/speculation-rules-improvements#eagerness) speculation rules would trigger a prefetch/prerender when the user hovers over a link (under the assumption that it's something the user wants to click). But the `interesttarget` design pattern (whether native or implemented in JS) means that users hover over links without the intention of clicking them. This introduces a tension that should be considered.
> 
> We look forward to any input you can provide on the above.

Hmm, interesting question! I hadn’t thought about speculation rules as they relate to `interesttarget` at all, so I really appreciate the pointer. I reached out to @tunetheweb to get his opinion on this question. The feedback was that while you’re right that there is a potential overlap between `interesttarget` and speculation rules, he feels that the [“hover for a period of time”](https://wicg.github.io/nav-speculation/speculation-rules.html#valid-eagerness-strings:~:text=moved%20the%20cursor%20over%20it%20for%20some%20time) condition for “moderate” may still be appropriate for links with `interesttarget`. His overall point was that in some cases, the developer might have provided “enough” information in the hovercard, such that the user is *less* likely to click. In other cases, the developer might have provided an “enticement” to the user, such that they’re *even more* likely to click. It should also be noted that “moderate=hover” is a Chromium heuristic that isn’t specifically required by the spec. Therefore, the decision should be left to the developer about how this should work with preloading technologies like Speculation Rules. His suggestion ([which I took](https://open-ui.org/components/interest-invokers.explainer/#interaction-with-speculation-rules-and-preloading-tech)!) was to add a section to the explainer for this interaction.


> ### With "Intent Events"
> `InterestEvent` is the first event that does not define any action, but a user intent directly. Imagine if we can define a whole set of such "Intent Events", then there are a lot of different things we can do. I can imagine the following, ranked by how far we go from the status quo:

This is a really cool point! I've been focused on just the narrow "interest" event, but you're right that it'd be great if we could define *all* input events in terms of their intent, rather than the specifics of how the user provided that intent. I'd say we do have another of those, `click`, which is just unfortunately named but actually represents an "activation" intent event.  Perhaps once `interesttarget` lands, it can be used as a template for other new things.

> [Close request](https://html.spec.whatwg.org/multipage/interaction.html#close-requests) is very similar in this respect. It establishes that a nonspecified and potentially device-dependent action can result in the closing of a `<dialog>` or popover and the firing of a `close` event.

+1 - close request is specifically to make "requesting close" independent of how the user did the requesting. @jyasskin also pointed out the [AOM input events proposal](https://wicg.github.io/aom/spec/input-events.html) as another example.





-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1058#issuecomment-2891786779
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1058/2891786779@github.com>