I'm requesting an early TAG design review of Interest Invokers (the interesttarget attribute).
Motivation
When you write @mfreed7 or #743 on Github, you get a link to the user's profile page or the issue/PR page. But if you hover over that link instead of clicking it, you get a nice "hovercard" popover containing more detailed information. Users really like this feature, because it gives them the bit of information they want ("who or what is this?"), including common quick actions like "Follow this user", without requiring them to leave the page, potentially losing state in the process.
Nearly all major sites include functionality such as this, ranging from small text-based tooltips to large interactive hovercards with useful links and buttons. However, implementing this behavior takes a remarkable amount of code. It must manage mouse hover and de-hover states, keep track of hover delays, implement keyboard activation, get accessibility right, and all of the related interactions. As a result, many developers' implementations aren't accessible to keyboard users, and none are accessible to touchscreen users. As a result, users who do not use a mouse do not have full access to the same information as those who do. The UA should provide this functionality natively, so we can do it right, and so developers don't have to keep re-inventing this wheel and/or leaving behind some users.
Proposed Solution
The Interest Invokers API is very similar to the Invoker commands API (explainer, spec, in that it also provides a declarative way to invoke actions on a target element. However, rather than being activated via a click on the element, this API uses a lighter-touch way for the user to “show interest” in an element without fully activating it. For example, a link <a href="..." interesttarget=foo> element can be hovered with the mouse, which might trigger a hovercard preview of the link, without actually navigating to the link destination URL. Of course, if the link is clicked, then a normal navigation will occur.
The API goes to significant lengths to ensure that the additional content is accessible, particularly for users not using a mouse or keyboard.
Security and Privacy self-review²: All answers are “no”, except this question <span>#</span>1, which is “What information does this feature expose, and for what purposes?”. The answer is: The env() variables expose screen real estate information, in a very similar fashion to the other such variables such as safe-area-inset-top.
Developers (as heard in OpenUI) are quite supportive. This API would not only remove significant burdens from design system implementation, it would also unblock solving this problem on touchscreens. This is presently not possible in a way that makes users happy. It also simplifies the keyboard activation story, and makes it possible to build completely declarative (no-JS) tooltips and hovercards.
Major unresolved issues with or opposition to this design: The mouse-hover based activation story is pretty clean and non-controversial. The keyboard- and touchscreen-activation stories are (necessarily) more complicated, and still in progress. Feedback on the current direction would be particularly helpful.
This is closely related to both the popover=hint feature, the commandfor attribute, and the anchor positioning API. This API (interesttarget) is the final piece needed in order to unlock the ability to declaratively build tooltips, hovercards, and menus that are triggered by mouse-hover or keyboard/touchscreen.
If you'd like to try out a prototype implementation, Chrome Canary with "Experimental Web Platform Features" enabled can be used with this quick demo: https://jsbin.com/cosusih/edit?html,output. Note that touchscreen behaviors have not yet been implemented, and details are again changing rapidly.
OpenedFeb 21, 2025
こんにちは TAG-さん!
I'm requesting an early TAG design review of Interest Invokers (the
interesttargetattribute).Motivation
When you write @mfreed7 or #743 on Github, you get a link to the user's profile page or the issue/PR page. But if you hover over that link instead of clicking it, you get a nice "hovercard" popover containing more detailed information. Users really like this feature, because it gives them the bit of information they want ("who or what is this?"), including common quick actions like "Follow this user", without requiring them to leave the page, potentially losing state in the process.
Nearly all major sites include functionality such as this, ranging from small text-based tooltips to large interactive hovercards with useful links and buttons. However, implementing this behavior takes a remarkable amount of code. It must manage mouse hover and de-hover states, keep track of hover delays, implement keyboard activation, get accessibility right, and all of the related interactions. As a result, many developers' implementations aren't accessible to keyboard users, and none are accessible to touchscreen users. As a result, users who do not use a mouse do not have full access to the same information as those who do. The UA should provide this functionality natively, so we can do it right, and so developers don't have to keep re-inventing this wheel and/or leaving behind some users.
Proposed Solution
The Interest Invokers API is very similar to the Invoker commands API (explainer, spec, in that it also provides a declarative way to invoke actions on a target element. However, rather than being activated via a click on the element, this API uses a lighter-touch way for the user to “show interest” in an element without fully activating it. For example, a link
<a href="..." interesttarget=foo>element can be hovered with the mouse, which might trigger a hovercard preview of the link, without actually navigating to the link destination URL. Of course, if the link is clicked, then a normal navigation will occur.The API goes to significant lengths to ensure that the additional content is accessible, particularly for users not using a mouse or keyboard.
env()variables expose screen real estate information, in a very similar fashion to the other such variables such as safe-area-inset-top.Further details:
You should also know that...
See also, whatwg/html#10309, which has reached Stage 1 of the WHATWG.
This is closely related to both the popover=hint feature, the commandfor attribute, and the anchor positioning API. This API (
interesttarget) is the final piece needed in order to unlock the ability to declaratively build tooltips, hovercards, and menus that are triggered by mouse-hover or keyboard/touchscreen.If you'd like to try out a prototype implementation, Chrome Canary with "Experimental Web Platform Features" enabled can be used with this quick demo: https://jsbin.com/cosusih/edit?html,output. Note that touchscreen behaviors have not yet been implemented, and details are again changing rapidly.