Finally, a CSS only solution to :hover on touchscreens

Mezo Istvan
ITNEXT
Published in
5 min readMar 15, 2019

--

TL; DR: It’s @media(hover: hover) and (pointer: fine) {} . There is an example towards the end of the article detailing this solution.

.hummingbird:hover {}

There have been problems with the :hover pseudo-class ever since the first web browser was installed on a touchscreen device. Of course there were solutions, but none of those were the solution. With the new Level 4 Media Queries, this issue seems like it’s solved for good.

‘Uhm… what’s the problem again?’

So let’s say you simply added a :hover styling to an element of your webpage, so it gets some styling when the mouse hovers over it. Easy.

Hovering on desktop. Source: https://proper-hovering.glitch.me

The problem arises when the user interacts with this element on a touchscreen: after the tap has been done, the hover effect is stuck on the element. This also occurs when the element is not even activated by the tapping, for instance if it was touched during scrolling.

If the dragging starts on the element, the hover effect is applied, because technically the pointer object (this is your finger most of the time) is over the styled element. This is a problem in itself: on a touch device, this translates as some unwanted interaction to the user.

However, it gets worse: after the dragging has stopped, the hover effect stays activated!

Hovering on touchscreen (emulated). Source: https://proper-hovering.glitch.me

This will definitely confuse some of your users, and that is never a good thing. Something needs to be done.

‘There must’ve been a solution already…’

Well, there are some, and most of them are covered in this excellent article. The best one of those includes using JavaScript to detect whether the screen has touch capabilities, applying a class to the body based on that and then explicitly referring to this class every time a :hover effect is added to any element.

body.nontouch nav a:hover {
background: yellow;
}

This has a few issues from the beginning:

  1. A developer can create the detection script that works well today, but what about in two months, when some new tech pops up? Laptops with touchscreens? Detachable touchscreens? Apple Pencil? I’d rather not worry about this during development.
  2. One would think that the JS community has a package ready and armed for just this problem, but that is not the case.
  3. When employing a component-based JS framework with encapsulated styles, this solution just throws a huge wrench in it. Any time hover effects are used, that component’s styles must reference this global class. Inconvenient.
  4. Not two projects that use this solution will be exactly the same. Maybe one works well on a special device, but not the other. There should be a standardized way to solve this.

Enter Level 4 Media Queries

Media queries are great. They singlehandedly enabled responsive web design, and are a cornerstone in today’s mobile first web development. As an excellent initiative, the W3C added Interaction Media Features as a candidate recommendation for L4 Media Queries, which we can use to distinguish touchscreen devices.

The four media queries included are hover, any-hover, pointer and any-pointer. These provide information about the hovering capability and the type of the user inputs. The info can be about just the primary input, or about any input that is available. For instance @media(hover: hover) will be true if the primary input can hover (e.g. a mouse cursor), and @media(any-pointer: coarse) will be true if any input is of limited accuracy (such as a touch input). These media features provide enough information to handle :hover properly.

One issue is that these queries are just a candidate recommendation at the moment, meaning that they could change or even be removed any time. Keep this in mind when working with them, and decide if it works for your project. This definitely works for us at the moment, and we have high hopes for these specifications. The fact that all major browsers have implemented these queries (except IE of course), makes us even more optimistic for the future.

‘So what to do exactly?’

From a developer’s view, we are looking for a solution that is the easiest to use and maintain.

From a UX perspective, we are looking for a solution that is the least confusing and the most enjoyable for the user.

This means no hover effects on touchscreen only devices, and using them everywhere else. The special case here is laptops with touchscreens, but there we can expect that the mouse/touchpad is used most of the time. Even if there is a stuck hover effect, the user can easily use the mouse/touchpad to double-check the problem and dismiss it. Fortunately laptops with detachable touchscreens will go into a tablet mode when detached, which the media query correctly handles.

Here’s a test site where you can test your own device to see which of these media queries apply to it, and also see some of the most popular devices’ settings. Browsers on Android have some inconsistencies, but the other devices seem to have these sorted out. Checking these different devices, he bottom line is that targeting laptops is possible with the query @media(hover: hover) and (pointer: fine) {}.

@media(hover: hover) and (pointer: fine) {
nav a:hover {
background: yellow;
}
}

Did I miss something? What do you usually use in these cases? I’m quite happy with this solution, but let me know if there’s a better one out there! 🤓

The cover picture is from here.

📝 Read this story later in Journal.

👩‍💻 Wake up every Sunday morning to the week’s most noteworthy stories in Tech waiting in your inbox. Read the Noteworthy in Tech newsletter.

--

--

Freelance senior web developer at Toptal 🔝, frontend at MindSciences 🧠