hoverDelay should depend on element (scrollable or not)

[jhogervorst]

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.

[jaspermdegroot]

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.

[jaspermdegroot]

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.

[jaspermdegroot]

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