Why does .hover() work on my iPad?

— Updated

The mouseover is a standard interface paradigm but in theory at least the mouseover and mouseleave events should not add any distinguishable behaviour to your website when browsing on a touch screen device, but that’s not quite what happens.

$('#cantTouchThis').hover(function() {
	alert('Apparently you can.');
}, function() {
	// But you'll struggle to escape
});
Adding mouseenter and mouseleave event listeners to an element with jQuery

There are select circumstances that will invoke familiar mouse events for compatibility and consistency—there could not have been such a huge surge in mobile web use if sites did not work on a touch screen—but they are limited to “clickable” elements such as an anchor or form buttons (Caveat: iOS will only acknowledge <a> or <area> elements with a href attribute as clickable) to reduce the risk of complex, device or application controlling gestures conflicting.

Mouse events are delivered in the same order you'd expect in other web browsers… If the user taps a non-clickable element, no events are generated. If the user taps a clickable element, events arrive in this order: mouseover, mousemove, mousedown, mouseup, and click. The mouseout event occurs only if the user taps on another clickable item.

Hacking an element to be clickable or misappropriating a clickable element might be a quick fix but it is not a solution, current browsers implement a delay before a mouse event is fired making the site feel sluggish and a pseudo-hover state will generally trouble users as it’s fiddly—especially for mouseleave or mouseout events. Until we have a unified API for detecting and handling user inputs a little manual work is required.

$('.toggle').on('touchend', function(e) {
    var o = e.originalEvent;
    var isTouch = o instanceof TouchEvent && o.changedTouches.length === 1;

    if (isTouch) {
        $(this).toggleClass('is-on');
    }
});
Adding a touch event listener to a toggle with jQuery , view source

Unlike a singular mouse cursor or keyboard focus a touch screen can have multiple, moving points of contact. Each TouchEvent instance is equipped with the current points of contact (touches) and set of changed points (changedTouches) so by using the two we can assume the users intention. Although the touch interaction may be slightly different to that of the mouse the solution is predictable and solid.

There is always a lot of trial an error when implementing touch controls, no one solution fits all—some interface design decisions just don’t work with a fat finger—but spending time to get the behaviour right is time well spent.

comments powered by Disqus

A photo of Matt Hinchliffe

About Me

I'm a 29 year old web developer building new stuff at the Financial Times based in London. I specialise in crafting scalable, performance-driven code, tackle accessibility issues and keep an opinionated interest in the latest hotness. I like my tea robustly brewed, white and with no sugar, thanks!