Update Menu component base item to have cursor pointer style for UX
Description
- Since we are in progress of updating the
DropDownMenutoAriakit Menua newer version, on checking the menu's in dataview or post actions, it seems that it is missing the basiccursor: pointer, style for the mouse interaction which can be an issue in terms of UX, as current implementation ofDropDownMenucomponent adds this UX experience, so we should consider it for theMenuspecifically toMenu.Itemcomponent.
See below recording,
https://github.com/user-attachments/assets/4cfdacc5-4c0b-41e4-a096-de09805a90ff
Since, all this actions are something which needs to be clicked, so we should be adding some UX experience instead of a normal cursor and update it to pointer.
Step-by-step reproduction instructions
- Go to any post/page edit screen.
- Check for the posts actions Menu item and hover to each menu item.
- You will notice it does not indicates that Menu Item is clickable and should improve UX.
Screenshots, screen recording, code snippet
No response
Environment info
- Gutenberg: Trunk.
- WP: 6.8.1
- MAC M1 AIR, Sonoma 14.5
Please confirm that you have searched existing issues in the repo.
- [x] Yes
Please confirm that you have tested with all plugins deactivated except Gutenberg.
- [x] Yes
Please confirm which theme type you used for testing.
- [x] Block
- [ ] Classic
- [ ] Hybrid (e.g. classic with theme.json)
- [ ] Not sure
Thanks for the report.
Personally, I'm in favor of adding pointer styles, but it’s a good idea to clarify whether the current implementation of the Menu component is intentional and whether the cursor:pointer style is really necessary.
If we really need the cursor:pointer style, it might be better to send a pull request to the Ariakit component itself rather than adding an override style in the Gutenberg component.
@diegohaz @WordPress/gutenberg-components
Thanks for the report.
Personally, I'm in favor of adding pointer styles, but it’s a good idea to clarify whether the current implementation of the
Menucomponent is intentional and whether thecursor:pointerstyle is really necessary.
Yes, I agree. If we look at the dropdown menu, it already uses similar styles. Since the menu item is a clickable element and triggers an action, adding a cursor: pointer would enhance the overall UX and make the behavior more intuitive.
If we really need the
cursor:pointerstyle, it might be better to send a pull request to the Ariakit component itself rather than adding an override style in the Gutenberg component.
Makes sense — contributing a fix directly to the Ariakit component would be a cleaner and more sustainable approach than overriding styles locally in the Gutenberg component."
Ariakit is an unstyled component library, so it wouldn't make sense to add the cursor: pointer style to it. WordPress components, however, are free to add any styles.
That said, I've conducted a few unscientific and informal usability tests with real users in the past. I would ask them to hover over elements on a page and determine (1) if the element was clickable, (2) if clicking it would navigate to a different page, (3) if clicking it would perform an action on the current page, and (4) if it was possible to open it in a new tab (with Ctrl/Cmd+click, a right-click, or any other method they were used to).
As long as the elements had a clear hover state, using cursor: pointer only for links and form submit buttons yielded the best results. Most people could predict the element's exact behavior just by hovering over it. When shown sites that used cursor: pointer for all interactive elements, they sometimes couldn't tell which elements were links (and therefore would navigate to a new page or if it was possible to open in a new tab) and which would perform an action on the current page.
This was enough to convince me that using cursor: pointer only for links and submit buttons provides the best UX, but it's not conclusive.
This is a very controversial topic. Despite this being the browser and OS default, the majority of the web now uses cursor: pointer on every interactive element, so that is probably the safest option. However, I believe a project like WordPress also has the opportunity to conduct more serious tests on this, so we don't have to rely only on opinions like mine.
We tried to do this once in the context of differentiating the disabled cursor state (#63816), but didn't really reach a consensus that it was a good idea. Though, I think we do have somewhat of an agreement that we shouldn't be overusing cursor: pointer for non-links. In any case this needs to be decided on at the design system level — right now we're not really consistent about it.