Chrome 139 is experimenting with Open UI’s proposed Curiosity Invoker API, which might be used to create tooltips, hover menus, hover playing cards, fast actions, and different sorts of UIs for displaying extra info with hover interactions. The Curiosity Invoker API makes these parts declarative and hover-triggered, that means that you simply create them with HTML, after which the net browser handles the mouseenter and mouseleave occasions for you, sans JavaScript.
You’d use it like this:
Curiosity set off
Curiosity goal
It’s not said wherever that they should be declared as popovers, however they do bake the precise accessibility hints in.
I need to spend slightly time trying on the items of this characteristic, how they‘re used as at the moment proposed, and supply a couple of ideas based mostly on my expertise taking part in with them.
Able to dive in?
The curiosity set off
The set off is what the consumer will hover (or long-press on touchscreen units) to disclose the curiosity goal. I’d name it an “invoker,” however to keep away from complicated it with the Invoker Instructions API (which is type of related), I’ll keep on with “set off” or “curiosity set off” for now.
The curiosity set off could be:
And it ought to have the interestfor attribute whose worth ought to reference the id of the curiosity goal. Listed here are examples for every supported aspect:
Curiosity set off
Curiosity goal
Curiosity goal
![]()
Curiosity goal
If the curiosity goal is a popover (like it’s within the examples above), then the interestfor attribute replaces the popovertarget attribute that’s usually required for declarative popovers. So, as an alternative of this:
Curiosity goal
…we’re taking a look at this:
Curiosity goal
The curiosity goal
The curiosity goal is what’s revealed when the consumer hovers (or long-presses) the curiosity set off. Once more, this needs to be a popover, and it’s vital to make use of the precise kind of popover as a result of they’ve completely different useful and accessibility behaviors.
popover attributes which might be worthless, empty, or use the auto key phrase could be dismissed flippantly, i.e., utilizing the esc key, or by clicking outdoors of the popover. When opened, these popovers shut all trace and different auto popovers (at the least, those that aren’t nested).
Curiosity goal
Curiosity goal
Curiosity goal
trace popovers (the most recent kind of popovers) can be dismissed flippantly, however solely shut different trace popovers when opened:
Curiosity goal
handbook popovers do their very own factor. They will’t be dismissed flippantly, don’t inform different popovers what to do, and we are able to have multiple of them open at a time. They’re suuuper chill.
Curiosity goal
Nevertheless, Open UI’s explainer and Chrome’s present implementation counsel that curiosity targets disappear on mouseleave no matter the kind of popover we’re working with. However redefining popover habits on this context (or any context) feels unsuitable to me. If the curiosity goal’s popover attribute is about to handbook, for instance, shouldn’t it persist after mouseleave?
Open UI discusses browsers baking the accessibility in relying on the popover kind, which justifies curiosity invokers constructing off of popovers, however I feel accessibility ought to rely upon the content material (until overwritten utilizing ARIA attributes) moderately than the popover kind.
Briefly, it looks as if curiosity invokers are designed for use with popovers however for all of the unsuitable causes (in my view anyway). That stated, it’s early days nonetheless. Curiosity invokers are very experimental and it’s definitely doable that I’m overlooking one thing.
They’re in any other case easy, which is on-brand for Open UI (take a look at the Customizable Choose, in spite of everything). They take commonly-used JavaScript-powered parts (similar to unique accordions, invoker instructions, and sure, popovers) and make them doable with declarative HTML.
That stated, there are some JavaScript occasions that we are able to use, too. Let’s check out these.
Curiosity invoker JavaScript occasions
Whereas I think about that you simply’d solely have to hear for the curiosity and loseinterestevents for sure edge instances, JavaScript occasions for these new declarative HTML options are pretty normal, and so they’re there must you want them:
interestTrigger.addEventListener("curiosity", () => {
/* Person confirmed curiosity */
});
interestTrigger.addEventListener("loseinterest", () => {
/* Person misplaced curiosity */
});However what does “curiosity” imply, precisely? That’s value digging into subsequent.
Curiosity delay (and the CSS of all of it)
You’ve in all probability observed that while you present or lose curiosity, there’s a brief delay within the popover displaying or hiding itself. That is extraordinarily annoying at first, however while you really begin to construct with curiosity invokers, you understand how essential it’s.
Right here’s the demo once more, so you possibly can attempt it out (in Chrome 139 or Canary for now):
One downside is that when you by chance mouseleave the curiosity set off and the goal (which could be very straightforward to do when the goal is simply too small), then all of it disappears. That is even extra annoying, however fortunately the conceal delay permits you some restoration time. Equally, the present delay presents keyboard and display screen reader customers the chance to skip the curiosity goal, whereas additionally stopping it from being triggered by chance with a mouse pointer.
Having stated that, if the curiosity goal is unobtrusive, then eradicating the present delay shouldn’t trigger any hurt. You can additionally take away the conceal delay for keyboard and display screen reader customers, who aren’t prone to “lose curiosity” by chance. We will do that by setting two new CSS properties, interest-show-delay and interest-hide-delay, to 0. The default is 0.5s and is about on the curiosity set off (however not the curiosity goal):
/* If unobtrusive */
.unobtrusive[interestfor] {
interest-show-delay: 0;
}
/* If keyboard-focused on a set off */
[interestfor]:focus-visible {
interest-hide-delay: 0;
}
/*
If keyboard-focused inside a goal of curiosity,
or goal of partial curiosity (these are at all times keyboard-triggered),
the curiosity set off that at the moment has curiosity
or partial curiosity has the conceal delay eliminated
*/
physique:has(:target-of-interest :focus-visible, :target-of-partial-interest) [interestfor]:the place(:has-interest, :has-partial-interest) {
interest-hide-delay: 0;
}Notice: Curiosity delays are at the moment buggy, particularly with unitless values. Generally they work, generally they don’t.
About these pseudo-selectors, although…
Mainly, when navigating to an curiosity set off utilizing a keyboard or display screen reader whose goal accommodates extra focusable parts, that is known as displaying “partial” curiosity. (I might’ve gone with “potential curiosity” personally, however I digress.) When this occurs, the curiosity goal’s focusable parts really aren’t focusable (making it straightforward to skip them, if wanted) until the consumer hits the choice+up/alt+up keyboard shortcut or equal display screen reader hotkey.
There’s even a message that we are able to customise by focusing on :target-of-partial-interest::after:
:target-of-partial-interest::after {
content material: "Press ⌥↑ to activate.";
}Whilst you in all probability shouldn’t change the message content material (because it shows the proper keyboard shortcut for the consumer’s system by default), we are able to model it by deciding on this fashion.
The consumer agent additionally throws this in:
:target-of-partial-interest {
interactivity: not-keyboard-focusable;
}The not-keyboard-focusable worth is new, and prevents the keyboard focus (like tabindex="-1" however for CSS, which is tremendous fascinating in its personal proper).
A full breakdown as a result of, frankly, that was lots:
:has-interest: Triggers with “mouse curiosity”:has-partial-interest: Triggers with “keyboard curiosity”:target-of-interest: Targets with mouse curiosity:target-of-partial-interest: Targets with keyboard curiosity:target-of-partial-interest::after: The message displayed when targets have keyboard curiosityinterest-show-delay: Theearlier than which the curiosity goal seemsinterest-hide-delay: Theearlier than which the curiosity goal disappearsinterest-delay: Shorthand forinterest-show-delayandinterest-hide-delay
It really works with anchors, too
Nothing actually new right here so far as what we’ve already mentioned, however I discover it cool that we are able to use anchor parts declaratively identical to curiosity invokers:
Conclusion
On the floor, curiosity invokers are merely hover-triggered popovers, however touchscreen units have by no means dealt with hovering effectively. As well as, hovering is vulnerable to human-error, and we definitely don’t need to drive keyboards and display screen readers to tab right into a minefield of focusables. There’s lots to think about, and Open UI have achieved an exquisite job of guaranteeing that consumer brokers do the lion’s share of it.
However there’s nonetheless extra to think about. For instance, how precisely would we open curiosity targets on touchscreen units? Lengthy-press + “View extra information” from the context menu appears to be the perfect strategy for the time being, however that’s a tricky one!
And, as we’ve mentioned, there’s lots for us to think about, too, similar to these delay timings and the way curiosity invokers needs to be styled. What ought to curiosity triggers and targets seem like after they have curiosity? What in regards to the hotkey instruction? We’re speaking about some new ideas right here, which may require new UX conventions.
Honorable point out: We’re additionally getting interactivity: not-keyboard-focusable out of this, which may assist us to construct keyboard-friendlier parts with CSS.
There’s lots to like right here, and I simply know that individuals are going to create unimaginable tooltips and hover playing cards and extra with this.
