Skip to content


Subversion checkout URL

You can clone with
Download ZIP


hoverDelay should depend on element (scrollable or not) #5464

jhogervorst opened this Issue · 3 comments

2 participants


I think it'd be good if the hoverDelay option was only applied if an element is in a scrollable area. Currently, you have to choose between a responsive feeling (low delay) or preventing unwanted taps (higher delay).

iOS handles this smarter: when you tap an object that isn't in a scrollable area, like a button in a header or a button in a screen that can't be scrolled, there's no delay. But when you tap a button (or cell) in an area that can be scrolled (like a table view/listview), a short delay is applied. Check the iOS Simulator on a (fast) Mac and you can see this clearly.

Unfortunately I don't have experience with development in bigger JavaScript projects (with unit tests and all); otherwise I'd have tried to implement this myself.


I like the idea, but doesn't this also affect swipe? We can't determine if a developer has bound a swipe event to an area.

Edit: Let me rephrase that... I guess it should be possible to check if an element or any of its ancestors has a swipe event bound to it, but I can imagine this is going to be very buggy and bad for performance.


In 1.4 we will use pseudo elements for button states instead of adding classes like ui-btn-hover-x. Our current implementation of hoverDelay won't work anymore. Question is if we need to come up with something to keep this feature or let browsers handle it.


We don't use hoverDelay anymore and leave it up to the browser. Closing as fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.