Are Hover Events Extinct?

by on 26th April 2012 with 18 Comments


Odds are, :hover was the very first pseudo class selector that you ever learned. Heck, it might be the only one you ever learned. We all love this lovely little feature and use it constantly as a way to create enriched user experiences.

My question today could change the way you think about hover forever: “Does the ubiquity of touchscreens render hover events obsolete?” Put another way, did the iPhone kill :hover? Read on to see how iOS handles a CSS hover event, what that means for you as a developer, and how you should or shouldn’t be using hover events in your designs.

Ode To Hover


I love CSS3. It has made pure CSS development so much more robust and flat out fun. Features such as transitions and keyframe animations bring us the kind of fascinating interaction that we once had to turn to JavaScript to obtain.

When you’re talking about animated events via pure CSS though, your options are fairly limited. Target gives us a way to do something while users have their mouse down, but a click and hold action isn’t necessarily intuitive on the web. There are other ways to fake a click interaction, such as perhaps modding radio buttons into a full blown slideshow, but these techniques are still pretty rare.

With keyframes, we have the ability to start an animation as soon as the page loads and even loop it infinitely. This isn’t always desirable though and can come with a decent processor speed hit for complex animations.

Then there’s hover. It’s a simple, easy to implement, easy to understand action that you as a developer can utilize to make user interaction a little bit better. With transitions, you can fade from one color to another, gradually reduce or increase the size of an object and even send it spinning in 3D space if that’s what you’re into. With hover, you have the ideal way to kick off all of these effects.

I’m all about hover effects and have written up several articles giving out free examples of my favorite tricks.

Trouble In Paradise


There’s a problem with hover events as a primary means of interaction, or perhaps I should say millions and millions of problems in the hands of people all over the planet: smartphones.

For decades we’ve had on-screen cursors, a strange but widely accepted means of interacting with digital content. Touchscreen devices, whether finger or stylus directed, have been around for nearly as long as the cursor, but the level of industry saturation was always quite low and let’s face it, none of them could handle the “real” web anywhere near well enough to even bother with.

Then came the iPhone. It wasn’t the first smartphone or the first touchscreen phone, but it was definitely a pioneer device in the world of a non-watered-down, touch-based mobile web. Fast forward a few years and the world is full of iOS and Android devices largely accessing the plain old, unadulterated web.

Most of us are now as familiar or even more familiar with touch-driven web interactions than we are with their cursor-driven counterparts. The big problem of course is that phones don’t currently sense your finger “hovering” above an element. This means that the experience doesn’t directly translate from one method of interaction to another.

This sounds like a small issue, but don’t brush it off. Touch interactions are fundamentally different than the traditional model and consequently many of our favorite tricks, such as hover events, need to be rethought. Don’t they?

What Does iOS Do With a Hover?


Obviously, touchscreens present a problem with hover events. One of the questions that came to my mind right away was whether this is my problem as a web developer, or a hurdle that device manufacturers were forced to tackle when they first developed their touch-based browsers. If hover is a fundamental way that we interact with the web, maybe the powers that be accounted for it in some way.

The best way to figure out what happens when you throw a hover event at a touchscreen is to try it out. So let’s code up a super quick and dirty example to test and see what happens. Basically, I just tossed a bunch of images into a div and set them to rotate on hover. Here’s the CSS:

body {
  background-color: #DDD;

div {
  width: 90%;
  margin: 0px auto;

img {
  margin: 30px;
  -webkit-transition: all 0.5s ease;
     -moz-transition: all 0.5s ease;
       -o-transition: all 0.5s ease;
      -ms-transition: all 0.5s ease;
          transition: all 0.5s ease;


img:hover {
  -webkit-transform: rotate(10deg);
     -moz-transform: rotate(10deg);
       -o-transform: rotate(10deg);
      -ms-transform: rotate(10deg);
	  transform: rotate(10deg);

The Live Test


Now that we’ve got ourselves something to test, let’s check it out on a touchscreen device. Grab your iPad or iPhone and tap here or on the image above to launch the demo page.

Obviously, nothing is going to magically occur if you hover your finger over an image, but what happens if you tap on an image?


It turns out, the hover effect actually works pretty well, it has simply been translated to a tap event. In our demos, none of the images are rotated by default, then when you tap on an image, the animated rotation occurs.

Interesting Observations

So we’ve established that hover events translate to tap events in iOS, and from what I can tell, a similar effect occurs on Android (possibly with an occasional double tap required). It’s important to note though not only that these events occur but how they occur and affect different circumstances.

For starters, you should be aware of the fact that once you’ve tapped on an item, the only way to cease that hover event is to tap on anther element that causes a hover event to occur. For instance, in this demo, tapping on the paragraph or the background doesn’t cease the hover event, only tapping on another image does.


The most significant revelation comes when we realize that most hover events occur on items that also serve as links to other items. This means that we have both a hover and click event on the same item.

As we know, touchscreen devices turn click events into tap events as well, so what happens when we combine two different desktop events that both translate to the same touchscreen event? As we can see in this demo, the animation begins when you tap on the item, but the click event quickly jumps in and redirects the page, even if the animation hasn’t finished.

Given that hover events are often used to help inform the user that an item is clickable, this discovery renders them largely useless in that regard.

Should You Abandon Hover Events?


The question that is at the core of this discussion is whether or not the hover pseudo selector has any place in your CSS in a time where so many people are browsing the web with touchscreen devices. So what’s the answer?

As far as I’m concerned, the answer is a resounding “yes,” although that comes with several stipulations. First off, it’s interesting to note that some projects will work great on many touchscreen devices despite their dependency on hover events. One example is an animated thumbnail gallery from a recent Design Shack article, which works wonderfully on my iPad. Another example might be a navigation dropdown menu that appears on hover, many of which work quite well on touchscreen devices despite the common belief that the opposite is true.

Despite this, I still absolutely recommend against relying on hover events as a critical method of interaction on mobile devices. To do so is setting yourself up for lots of user headaches. Given the range of different touchscreen browsers and devices, you can’t be certain without a ridiculous level of testing that hover events translate the same way on all of them.

Consequently, my advice is to always assume, regardless of the truth of the statement, that the hover interaction model won’t work for smarthphone and tablet users. This assumption does not however, prevent you from styling the hover selector in all your work and even using some fancy hover effects once in a while. Just keep in mind that the user’s success should not depend on this action, rather it becomes more of a progressive enhancement situation where everyone can use your site at its most basic level and desktop users can enjoy a few visual thrills that touchscreen users might not ever see.

Optimization Via Media Query


If you want to go further and clearly differentiate the experiences of your touchscreen and desktop users, you could write up some simple JavaScript, but I’m a big fan of using CSS wherever possible so my mind instantly gravitates towards a media query driven solution.

You can use media queries to ensure that both mobile and desktop devices have an optimized experience. For example, a list of links might have a small clickable area and a nice hover effect on a desktop while having a large clickable area and no hover effect on a mobile device.

But let’s say we wanted to go further and actually make the big screen site completely dependent on a hover event to function properly. This is acceptable because our media query will ensure that mobile devices have a different model, right? Perhaps not.


Throughout this article I’ve constantly contrasted touchscreen devices with desktop computers. The inherent assumption here is that all touchscreen devices have small screens. It occurs to me that, while this is conveniently correct in most cases today, it’s an entirely faulty assumption that especially breaks down over the long run.

I personally believe that touchscreen interaction will only become more popular in the years to come. A touchscreen PC or laptop might be a rarity now, but I’m not sure it’s a safe assumption that this will hold true long term. This means that even though using a media query to detect screen size might seem like a great way to differentiate between touchscreen and cursor-based devices today, it’s probably not the best practice to get into as the twenty inch screens of tomorrow might use touch interaction as much or more than they do cursors.

Use Hover Wisely

Is hover extinct? Nope. Will it be extinct any time soon? Probably not. Is it becoming increasingly hazardous to rely on hover events as a primary means of interaction with the user? Absolutely.

I’ll still use hover styles and even continue to dish out fun hover effect tutorials, but I definitely want to make it clear that I think the days of allowing your site to rely on hover to function are long gone. Unless the next iPhone senses your finger hovering over the display, touchscreens complicate this interaction model enough that you should typically assume that it simply won’t work on these devices (be they small or large).

What do you think? Are you careful about how you apply hover styles in CSS? Where do you draw the line for using hover as a point of interaction? Do you think touchscreens will continue to increase in ubiquity? I’d love to hear your thoughts.

Comments & Discussion


  • Mary Baum

    I think this is spot-on. If Apple had plans to make iPhones sense a hover event, I think we’d have seen it by now – it doesn’t seem as if it would have been that hard to build into the OS. That said, I think it’s probably incumbent on us to make better use of the focus state – nah, I don’t suppose that’ll work either – or as you alluded to, somehow make the hover area and the click area different sizes that overlap. The price for that is we’ll have to spend time telling users how to interact with these elements in places like picture captions, but digital magazines like Oprah’s (yes, I’m 52 and I write CSS) already do that.

  • Larry Killskee

    Really? An article about how relying on hover events to indicate tappability on mobile is bad?

    An actually interesting angle to this would’ve been how hover dropdown menus employed by some sites actually function on iPad and iPhone just fine, precisely because hovers are translated to taps. What’s actually important and relevant is that it’s possible to use hover events to hide and show content on both mobile devices and on the desktop as long as you’re using elements other than “A” tags, or remove the HREF attribute from each. In other words, a hover dropdown with its title unclickable will work perfectly on a touch screen.

  • Jack Nycz

    He literally sates that there are some cases – such as the one you just described – where hover events are perfectly fine on touch screen. “First off, it’s interesting to note that some projects will work great on many touchscreen devices despite their dependency on hover events.”

    Anyways, I full heartedly agree with you. I’ve come to use hover in a billion different ways, and as I’ve moved into responsive web design and targeting tablets and phones in the last two years it’s become increasingly aggravating to design a wonderfully interactive bit of a site only to have it fail totally and completely because of the lack of a true ‘hover’ state on touchscreens.

  • Joshua Johnson

    Larry, you gotta read the article before commenting dude, it’s the rules! :) I discussed the exact topic that you’re saying you wish I had discussed.

    “Another example might be a navigation dropdown menu that appears on hover, many of which work quite well on touchscreen devices despite the common belief that the opposite is true.”

  • Damian Smith

    I don’t think Hover will ever be obsolete, it will though test the designer/developer into making sure the effect will be worthwhile for all device types.

    I still use hover, as an example my website has a hover effect on the portfolio and a button appears within the image to click into more info.. on an iPhone you simply click the image for the effect and then it clearly states to click the now appeared button to read more.

    Nothing wrong with that kind of use, and I can’t see this dying out as long as it is thought about well enough before hand.

    Thanks for the great article!

  • Bharat Chowdary

    Interesting one, I like the images used in this article.

  • Trey Copeland

    Interesting article. Hovers will not go away. As long as we have BOLD font type, we will have hovers. This article was pretty much pointless. Almost as pointless as me commenting on it.

  • Jim Zalewski
  • Karl Kelman

    An underlying question here may be:

    Are Mobile and Touch Devices really the future?

    Yes, the are enjoying market share growth now, but it’s possible that there’s an element of faddishness in that growth. I like my smartphone, but it’s utilitarian for me; the beautiful graphics, fast loading videos, and other things that make the web fun belong on my brand new desktop computer with a high-speed wired connection.

    All the cool kids buy an iPad: But once they discover it’s slow, and renders the millions of iPad unfriendly sites badly (no flash, etc.), it will gather dust.

    The possibilities for beautiful graphics and complex interactivity with CSS3, WebGL, etc. may, paradoxically, lead to a revival of the plain old fashioned desktop.

    It’s possible that mobile devices will need to adapt better to the web, instead of the other way around.

  • sushil bharwani

    Nice article. Hover will continue to exist and play important role as described in the article. However it becomes clear that with touch based devices use of Hover has to be extra careful.

  • best of el

    Now we already have smartphone with hover event: Sony Xperia Sola. And Android 4.0 and above already have hover event. Google for it.

  • Rita Dawson

    I am impressed with your simple question – “Does the ubiquity of touchscreens render hover events obsolete?” I have also been wondering about this from a long time. As you say, Touch screens do have problem with Hover events and I think iPhone has killed Hover. Anyways, Thanks for the interesting article. I enjoyed reading it and I learned a lot from the phrases used.

  • ianf

    Now that Karl Kelman has pronounced the iPad’s imminent death (in his neighborhood full of cool kids anyway, which is all that matters), I suppose we should be discussing something else than hover or not to hover. Only it won’t go away. Because, unlike physical-click/tap events that are all conscious interactions, hover is the premier route for subconscious content perusal and (perchance serendipitous) in-page discovery. As such it is much too powerful a method to disappear off the wo/man-computer dialogue map entirely.

    That said, hover is just one of the elements of interaction, of which hardly all are platform-, os- and browser-independent. So the problem is not whether “object:hover” acts exactly the same in touch conditions (it won’t), but how well, and how consistently it degrades. As probably will other elements on the same page. It is therefore up to the designer to ensure that desktop-hover either be non-critical, redundant, or suplementary to other user actions in touch cases.

    PS. I was a cool kid once; still am, internally.

  • ianf

    Incidentally, here’s what ppk has found out as regards existence of and detection of :hover on WebKit and in other touch engines:

    > The iPhone fires a mouseover and :hover
    > when the user first touches the element.
    > It fires a mouseout and removes the :hover
    > when the user touches another element.
    > Essentially, the element retains the
    > focus until another element is touched,
    > and mouseover/out and :hover are tied
    > to this focus exclusively.

  • AntoxaGray

    I hate hover dropdown menus because it always pops out when I move cursor around.

    This is not issue on iPhone because you have actually to «click» it, that’s how it should be coded for PC browsers in the first place.

  • Peter

    I’m an amateur, not a programmer. When I was building a page that needed to display information only on hover, I did my usual research by search engine. I found a lot of experts advising me to give up the whole idea and make all the information visible.

    It’s true that some hover applications aren’t necessary, but many have been done that way for good reasons. It’s silly to let touch screens give up those advantages completely. I suspect it will ultimately be the touch browsers, not the applications, that adjust.

    I managed to figure out on my own that using anchors without hrefs — and with tooltips — would get the touch screens to cooperate. As was noted here, you have to tap again to close the information windows, but in my application that wasn’t a problem. (If any of you experts would like to comment on this workaround, it’s here: )

  • Phillip

    IMHO I believe that touch and effects from the hover/rollover to the JS accordion will be distinguished by hardware like a pen attached to the cell phone or tablet. Touch and screen sensitivity levels for initiating a hover instead of a click is like adding an additional level of navigation and user experience for a user to get to their destination? I believe that the pens will get even better than the Cintiq by Wacom and maybe there will be a default setting that when docked with device hovers are activated or maybe the pen will have a button or pressure sensitivity to activate the hover. Again, this would be the progressive direction I would go…hmm?

  • boca raton computer forensics investigator

    I am really delighted to read this web site posts
    which includes lots of helpful information, thanks for providing such data.


About the Author