:hover is dead Jim.

The :hover pseudo-class is dead, it just hasn't fallen over yet. In fact it's not just dead, it was murdered. Killed by the touch interface.

I'm not exactly clear on when :hover was created or by whom. It was included in the May 1998 CSS2 specification and I believe Microsoft's Internet Explorer 5.5 beta in December 1999 was the first browser to implement it (but only for the "a" tag, which is still true today). I've seen reference to Microsoft having invented it and contributing it the CSS specification. It was subsequently supported in other browsers.

You've seen :hover everywhere on the web for the last decade. Initially web coders fell in love with it because it provided a pure CSS method for doing image rollover and show/hide effects that previously had required Javascript to work. Because the W3C never limited what elements could be assigned the :hover pseudo-class it meant that (aside from IE) you could make hovering over any element you chose trigger a CSS event.

In many ways you could argue the ubiquity was actually an abuse of the function, and I've seen blogs decrying it as a crutch for bad user interface design (an easy hack to selectively show content that otherwise didn't fit into the layout). On the other hand it could also enhance the user interface by providing feedback to users regarding what was "interactive" and what wasn't or providing contextual information depending on with what element a user was - or was about to - interact.

If you think about it the :hover pseudo-class is actually a pretty amazing little bit of shorthand. It tracks the pointer position when it is over the coordinates of the element to which it is applied and can perform actions based on that detection. Take something as simple as the very common image rollover on a button - with :hover it can be accomplished in one line of code that single line could create the rollover effect for EVERY button on the page. Try to accomplish the same thing with Javascript and you'd have to give unique IDs to each button, create custom functions that could be called from those buttons that defined variables for the height, width, and top+left coordinates of the button itself and then another function to track the mouse coordinates and yet another function that performed the swap-out on that button, but only if the mouse coordinates were within the same area defined for that particular button. That fact that :hover can accomplish all that in one line of code is frankly. . .beautiful.

Then along came "touch" interfaces. PalmOS, iOS, Android, WebOS - all the mobile operating systems for touchy-feely devices like the Blackberry, Droid, iPhone, iPad, iPod Touch, Galaxy Tab, etc. They don't DO hover effects. Why? Because the "hover" represents a proximity-based feedback and touch devices have no way to detect if you are "near" or "about to interact" with an element. You're either touching it or you're not.

In touch interfaces there is simply nothing similar to hovering - of if you prefer the Javascript mouse event name for it "onmouseover." Which is what we're really talking about here - are touch equivalents to mouse events:

mousedown = touchstart

mouseup = touchend

mousemove = touchmove

mouseover = ???

mouseout = ???

click = "Tap" (click actually generates a mousedown+mouseup, so tap is a touchstart shortly followed by a touchend event)

dblclick = Two quick "taps" (dblclick is rarely used, but technically you could script touch events looking for two taps in quick succession on a single element)

contextmenu = touch and hold (keeping in mind this triggers default touch callouts for things like saving images or copying text. If you wanted it to display a custom context menu you'd have to disable the default touch callout and try to detect a touch and hold event by timing how long a touchstart on an element sustains without a touchend event)

Additionally, in the "mouse centric" desktop world you only have ONE pointer. It's ALWAYS on the screen at some coordinates. In the "touch centric" world the "pointer" doesn't exist until a finger touches the screen, and in the case of multi-touch interfaces you might simultaneously have five or ten "pointers" to track on the screen!

The :active pseudo-class is the CSS way of detecting a mousedown event but it generally won't trigger an active state class change with touch interface "touch and hold" even if you've disabled the default touch callouts - you'd have to add a touch event listener to the element and trigger the style change from javascript. I've had success using the :target pseudo-class on "a" tags to get a touch interface to trigger onclick type events (for example hiding a layer), but it's clumsy.

In fact I'd say the one thing I presently do NOT like about coding for touch interfaces is how clumsy it is. You're stuck using Javascript to accomplish anything with it - even when you are using touch-specific CSS extensions, you still need scripted event listeners to make the elements touch-friendly. Ideally what we NEED is a :touch pseudo-class that does all the heavy lifting - but with no agreement in the industry on how touch interfaces work we're probably forever saddled with scripting and proprietary code and classes.

You can DISABLE various default touch behaviors via webkit CSS extensions:

-webkit-touch-callout: none; (prevents the "right-click" style options on a long press)

-webkit-tap-highlight-color:rgba(0,0,0,0); (prevents "highlight" color on touched links)

-webkit-text-size-adjust:none; (prevents automatic text resizing)

-webkit-user-select:none; (prevents elements from being selected by touch)

What does that mean for the web? It means as pages are optimized for interaction with touch interfaces all the "mouse-centric" methods will go away, relegated to obscurity. The word to the wise these days is to not only design for mobile devices, but to design for TOUCH interfaces. That means you don't use :hover or :active in your CSS anymore. That means you add support for touch events and selectively disable mouse events (because there is inconsistency between mobile devices regarding the interpretation of mouse events as touch events - a single touch can trigger a slew of mouse events all at once, which can cause unwanted results if you've coded the page to do certain things depending on each mouse event).

There simply is no touch event that is similar to hovering, so don't use it anymore. Actually the W3C was aware of this from the start as the CSS2 specification state that some input methods (it specifically mentions pen input, which is a lot like single-point touch) as not being able to support the :hover pseudo-class. If stylus input methods had become popular at the start of the 21st century we'd probably have seen :hover fade away before it even got going. But here we are decade later and touch is input method of choice. Sorry :hover, you have to die. The mouse will likely be keeping you company in your crypt soon enough.