What is the reasoning behind giving focus on hover?

[Joonaspraks]

Hi!

When we hover on for example these menu items here they gain focus. What's the source behind this behavior? Is it in some aria specs? Given how prevalent this pattern is (at least in react-aria) I hoped to find more resources backing it up, but currently this is the only post I've seen referencing it.

Thanks in advance!
Awesome project!

[Sidnioulz]

This is a problem I'm having at the moment with MenuItems. I understand setting data-focus and :focus state triggering, but mixing :hover and :focus-visible by programmatically focusing a hovered item makes it difficult to style hover states.

We end up having focus rings on hover. We do want very visible focus rings, but we also have a background colour for hover states, and the focus ring feels like overkill. We want the focus state to have higher visibility because it's harder for KB users to guess where focus will be transported to, whereas pointer device users always know where their pointer is.

[snowystinger]

Sorry for the delay @Joonaspraks, it looks like we missed this issue. I'll do my best to answer the questions here:

You should be able to use the renderProps for isFocused and isFocusVisible, or the data-* attributes in order to determine if you should show the focus ring. We recommend doing this anyways because all the browsers handle :focus and :focus-visible differently. See https://react-spectrum.adobe.com/blog/building-a-button-part-3.html#focus-rings

As for why focus is given on hover, that matches the native behaviour for menus and selects. You can see this by trying the https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/select component. Open it with your mouse, then hover over an option and press the "Enter" key. Note that the option is selected.
You can also see this behaviour in the menus on a Mac, if you're in Chrome, go to the Tab menu across the top of the screen. Hover over "New tab to the right" and press enter.

[Sidnioulz]

Thanks for the comprehensive explanation, @snowystinger! It does make sense to me now why you made those choices and why they're optimal in an environment where the entire UI is powered by Spectrum.

In our case, as we already have our own Select, I want to ensure our Select and Menu behave similarly. If we made our Select conflate hover and focus, we'd have unwanted externalities as

• we perform selection on focus like a native select
• many of our selects trigger CPU-intensive processing, so we'd end up having to debounce selection on hover which would likely feel weird

Do you know if I would be able to rebuild menu without this state mixing using lower-level hooks, for our own consistency within our product?

[snowystinger]

Do you know if I would be able to rebuild menu without this state mixing using lower-level hooks, for our own consistency within our product?

Possibly? I'm trying to figure out where we do that in Menu, since it doesn't use the listbox hooks where we have a prop to control this. But it eluded me in my quick search just now.

One other case I remembered. As you hover items, if you press the up/down arrows, it'll move focus from the currently hovered/focused to the next enabled item in that direction.

[Sidnioulz]

Possibly? I'm trying to figure out where we do that in Menu, since it doesn't use the listbox hooks where we have a prop to control this. But it eluded me in my quick search just now.

I suspect it has to do with persistedKeys in the underlying Collection? Do persistedKeys get used for event handling anywhere on top of virtualization?

I also see the selection-related hooks that set activedescendant but I don't see that attribute in use in Menu.

I haven't had time to sit down and inspect the codebase in depth yet but I have to say this one isn't obvious!

As you hover items, if you press the up/down arrows, it'll move focus from the currently hovered/focused to the next enabled item in that direction.

Neat little detail! And I see you prevent mouse events on the previously hovered item from re-triggering it.

[snowystinger]

Persisted keys don't have an special event listeners, they are there to keep certain items always in the dom in virtualized cases. Some examples are things like sections which are needed to label items that are in view, the currently focused element so that tabbing away and tabbing back will scroll that element into view automatically, and drop targets for drag and drop. All of these may have their own event listeners, but don't receive any special new ones.

Our components aren't virtualized by default though, so I theoretically we shouldn't need to look in this direction. Even in our Spectrum implementations we don't virtualize Menu.

The usual suspects would be something like:
top level hooks
useMenu->useSelectableList->useSelectableCollection
individual items
useMenuItem->useListBoxOption->useSelectableItem
others
KeyboardDelegates which are passed to the above hooks and influence the events they handle

I'm not sure how I missed it last time, but looks like we do the focusing on hover here

react-spectrum/packages/@react-aria/menu/src/useMenuItem.ts

Line 262 in 661ba8e

selectionManager.setFocusedKey(key);