Opened 12 years ago
Closed 11 years ago
#17049 closed enhancement (duplicate)
Add hoverIntent to new AdminBar
Reported by: |
|
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)
Change History (10)
#2
@
12 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:
↓ 5
@
12 years ago
About the 'no-js' class: we already have 'hide-if-no-js' and 'hide-if-js'.
#5
in reply to:
↑ 3
@
12 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
@
12 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
@
12 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).
+1. I've had users complaining about this as well.