WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 3 years ago

#17049 closed enhancement (duplicate)

Add hoverIntent to new AdminBar

Reported by: cgrymala Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.1
Component: UI Keywords: has-patch ux-feedback
Focuses: Cc:

Description

I would love to see some sort of hoverIntent effect applied to the new AdminBar. I took a look at the source and noticed that a timeout of 500 milliseconds is already applied to some of the menus in the AdminBar onmouseout. It would be great to see the same sort of timeout applied onmouseover; keeping the menus from appearing immediately on hover (especially with the timeout applied to the onmouseout event).

While I love the added features found in the AdminBar, it is far too annoying for me most of the time, when I move from the address bar in my browser to somewhere on the page, and items in the AdminBar start popping open automatically (then wait up to half-a-second before going away).

I am planning to investigate this to see if I can come up with a patch; but I thought I'd submit the enhancement request just in case someone out there already had a simple patch in mind. Thanks.

Attachments (1)

wordpress-adminbar-hoverintent.diff (18.0 KB) - added by cgrymala 3 years ago.
Proposed patch to add hover intent to the dropdowns on the new AdminBar

Download all attachments as: .zip

Change History (10)

comment:1 scribu3 years ago

+1. I've had users complaining about this as well.

Last edited 3 years ago by scribu (previous) (diff)

cgrymala3 years ago

Proposed patch to add hover intent to the dropdowns on the new AdminBar

comment:2 cgrymala3 years ago

  • Keywords has-patch added

I've added a patch that seems to work on my test environment. It adds a 200 millisecond timeout before displaying the menus; and keeps the 500 millisecond onmouseout timeout in place.

comment:3 follow-up: scribu3 years ago

About the 'no-js' class: we already have 'hide-if-no-js' and 'hide-if-js'.

comment:4 scribu3 years ago

  • Keywords ux-feedback added; ui-feedback removed

comment:5 in reply to: ↑ 3 cgrymala3 years ago

Replying to scribu:

About the 'no-js' class: we already have 'hide-if-no-js' and 'hide-if-js'.

I initially thought about using those, but I don't think those classes are definitively used outside of the admin area, though. They could potentially be left out on the site itself, depending on the theme that's used, couldn't they?

comment:6 scribu3 years ago

Yes, unless they were added to the admin bar css. Even if we duplicate the definition, it's better to have consistent names.

comment:7 cgrymala3 years ago

That's a valid point, but, from what I can see, we are also using the no-js and js classes (at least within the admin area). When I disable JavaScript and visit the wp-admin area of my 3.1 installation, the body has a class of wp-admin no-js ...

If you think it's better for me to use hide-if-js or hide-if-no-js instead of no-js, that's certainly an easy enough change to make, but I was trying to be consistent from the get-go.

In addition, I think the concept (at least, based on their names) of hide-if-js and hide-if-no-js is different than the concept of no-js. I'm not hiding or showing anything with JavaScript, I am simply using it to determine whether or not JavaScript is active in the browser (if it's not, we use the standard CSS pseudo-element :hover; if it is, we use JavaScript to add a hover class to items after the timeout occurs).

Last edited 3 years ago by cgrymala (previous) (diff)

comment:8 AllStruck3 years ago

  • Cc AllStruck added

+1 Bump: I'd love to see this in immediately, I view this as a bug.

What could I do to help move this along?

FWIW: This is my first time getting into WP trac at all but I want to help any way I can.

Thanks!

comment:9 ryan3 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to duplicate
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.