Ian Nicholas

Hover Is Dead; Long Live Hover

Is it just me, or have some of the visitors lately been a little… well… spooky. They drop in, scroll around a bit like normal, but then—somehow, with no warning at all—we're clicked on. It's disorienting. Their sneaking up on us wouldn't bother me so much, really, but… I could swear there are more of them every day.
—a :hover to its a element

Yes, it's a scary time to be a hover state. The venerable CSS selector and the JavaScript events that sprang from it have seemingly always been here, fully supported by nearly every browser out there. But there are some new kids on the block, and these upstart smartphones and tablets think it doesn't even exist. To them, there's no such thing as a hover. Interacting with a page element is a purely binary proposition—you are not touching it, and then you are.

A Brave New World

While I hope no one is losing sleep over mobile users being unable to fully admire a slick color transition from periwinkle to cyan, their inability to trigger events through hovering has deep implications for designing a web interface that works for all comers. If you have, for example, a dropdown menu, and the top-level link normally fulfills two functions—hovering triggers the submenu, while clicking triggers the main link—how could that work in an environment where mere interest (normally triggered by hovering) is indistinguishable from action (tapping)?

The hover has a new, unfamiliar world to contend with. While it's true that regular old mouse-and-keyboard geezers still make up the vast majority of the traffic on the web, there's a definite exponential look to the trend lines:

Obviously, the mobile web is here, getting bigger, and is making demands about how we design interactions on the web.

What Do We Do?

Trent Walton calls hover a "crutch," and writes that the best approach to this problem is to build specifically for touch, show everything at once, and use hover states only for superficial enhancements.

I can't help but think the hover state fills too many hard-to-replace roles in interaction for designers (both software and hardware) to consider relegating it to the realm of low-impact bling. A hover is an expression of interest that lies between non-action and action, and it opens useful channels of knowledge. Put your cursor over an image or link and see if it turns into a hand. It did? Guess it's a link. Where does it go? Ah, there's the address in the bottom left.

Not to mention a hover is also that rarest of interactions—one that doesn't require any extra brainpower or practice. In any cursor-based interface, as soon as you learn how to click on things to activate them, you've already learned how to hover. It's about as intuitive as they come.

On a phone, things look and feel different. If you see an image or a link on a web page, there are two channels through which you can learn what it is and does: you can look at it, or you can tap on it. Before tapping on it and potentially opening a new web page (an action with tangible costs in the mobile world), all you can know about it comes from its pixels, and context clues.

Sounds like I'm splitting hairs, maybe, but I believe these interactions have a subtle but profound effect on the way we consume web pages, and their absence is a major deficiency in the mobile web. We learn a lot just by passively scrolling down a page, unconsciously hovering over parts that interest us and seeing what they do. Without that stepping stone, mobile browsing feels more opaque, more haphazard.

I believe subjecting all web designs to the lowest common capabilities of the market and showing everything at once to everyone is a step backwards, and defeats much of the dynamic advantage the web holds over static media like printed posters. While we should always keep touch interfaces in the backs of our mind when conceiving of any interactive element, I think it's a mistake to shy away from things like dropdown menus or hidden actions just because they're potentially problematic in mobile.

Go For It

I approach this as a regressive enhancement exercise, and serve up the richest experience to the browsers that can handle it, while delivering fallbacks to detected touch browsers. In this endeavor, Modernizr is our friend. The .touch or .no-touch CSS body classes and Modernizr.touch JavaScript variables, while imperfect, allow us to target mobile browsers with any necessary adjustments to the interface.

There are plenty of subtle pitfalls. Fortunately, though, mobile browsers are generally adept at translating their vocabulary of swipes, pinches, and taps to that of a web that was and is, for the most part, designed with mice, for mice.

If the user taps a clickable element, events arrive in this order: mouseover, mousemove, mousedown, mouseup, and click.
Mobile Safari documentation

Due to this mouse-mimicking model, often a tap is a valid way to trigger what would be a hover state in a desktop browser.

Is This Gonna Be Forever?

Tablets and phones have made the hover state an endangered species, and ultimately it's up to the makers of these devices to decide its future.

Apple has made some interesting motions toward accommodating it, but Jobs' philosophy had always focused on taking away that which he felt was unnecessary—whether that's the computer tower, additional mouse buttons, or hover states. And I doubt his company will take any bold steps away from that path any time soon. Android developers and Microsoft are more likely candidates to introduce something new, but the forces of inertia and "good enough" are strong.

Still, I can hope some clever engineer comes up with a neat analogy. I find it interesting that even the cheapest smartphones nowadays have front-facing cameras for video chatting. Recent Android versions even feature facial recognition so precise that you can depend on it for locking your phone. Presumably if the camera is sharp-eyed enough to recognize an individual's face, it could also learn to follow a person's gaze onto its own face. Is it so far-fetched to imagine something like the user's gaze filling the role of :hover? I hope not.