A partial archive of discourse.wicg.io as of Saturday February 24, 2024.

Hover emulation on touch devices


Am I correct that the de facto standard of emulating CSS :hover & JS mouseover/mouseout/mouseenter/mouseleave on mobile touch devices via “tap-and-hold” (as on iOS Safari, Android Chrome, etc.) isn’t standardized at all or even mentioned in a non-normative note in any of the relevant Web standards? Is it in-progress or under discussion at any WG?


Nope, the definition of “hovering” is up to the device and host language, and is a quality-of-implementation kind of thing.


Well, the “you can’t hover on touch” meme is still out there in the wild (particularly in old articles/posts), so note(s) would still be nice, imho.


I think a non-normative note for the fact that is is a de-facto behavior in the Living Standard would be appropriate. That’s the whole point of the HTML LS: to document the world, not ignoring how the way we’d like it to be differs from how it is.

To address the behavior itself for a minute, though, I think it’s pretty stupid. Touching and holding something is nothing like hovering on it. Most capacitive touch devices (or at least laptop trackpads) are sensitive enough to detect a finger <5mm off the surface (and Microsoft / Wacom styli have reported - and used - hover for decades): that should be your damn hover. Not some action that, if I change my mind halfway through taking it, turns into a click.

And, further, the “hover triggers something important (like menu expansion)” pattern needs to DIAF, not just because it’s bad for touch, but because it’s bad usability, period. Hover should be like HEAD requests in HTTP: No side effects, and nothing that doesn’t happen when you make (a GET request / a click). The world definitely should acclimate to a theoretical environment where hover doesn’t exist, because hover should be incidental: it’s something users can do inadvertently. (This is especially going to become an issue as eye-tracking environments like Glass and Oculus grow in popularity, where users have to practice averting their gaze from menus to avoid hover triggers.)


The Touch Events spec defines what you mentioned regarding mouse event emulation here: http://www.w3.org/TR/touch-events/#mouse-events

Unless you are implying that Touch Events is not a relevant web standard.


Unfortunately the exact rules for applying :hover (and even :active) with touch aren’t consistent between browsers. Eg. What’s the order and timing of mouseover events vs. :hover being set. There are lots of subtle details and tough web compat issues at play. We’ve talked in CSS WG and TECG about trying to standardize this - IE, Chrome and Safari have all expressed some interest in improving interoperability and understanding here. I expect we’ll make at least a little progress on this over the coming months.

By the way, we have a pretty cool experiment enabling true touchscreen hover support in Chrome on the Samsung Galaxy S4: http://crbug.com/418188. I’ll post a video once it hits Beta. Its not clear we want to enable something like this by default (I agree hover is a broken UX paradigm), but its still a cool demo.