Make WordPress Core

Opened 9 years ago

Closed 9 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:


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 9 years ago.
Proposed patch to add hover intent to the dropdowns on the new AdminBar

Download all attachments as: .zip

Change History (10)

#1 @scribu
9 years ago

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

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

9 years ago

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

#2 @cgrymala
9 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.

#3 follow-up: @scribu
9 years ago

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

#4 @scribu
9 years ago

  • Keywords ux-feedback added; ui-feedback removed

#5 in reply to: ↑ 3 @cgrymala
9 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?

#6 @scribu
9 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.

#7 @cgrymala
9 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 9 years ago by cgrymala (previous) (diff)

#8 @AllStruck
9 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.


#9 @ryan
9 years ago

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