Pointer

Amazon's menu prediction cone

A screenshot of the Amazon menu, with a triangle/cone overlaid demonstrating the region wherein the menu will remain locked to the current item if the pointer doesn't stray outside of it.
A visualization of the mathematical cone that Amazon uses to predict the menu item you're heading for. Cone is not actually visible.

Standard drop-down menus that contain sub-menus very often have no concept of user intent, and this can lead to a repeating frustration that most of us have likely run into: straying off course by even a single pixel can cause the sub-menu to close instantly. Ways around this include adding a delay to try and account for user error, but that doesn’t feel as snappy. Amazon has a really clever solution that accounts for user error yet responds instantly:

At every position of the [pointer] you can picture a triangle between the current mouse position and the upper and lower right corners of the dropdown menu. If the next mouse position is within that triangle, the user is probably moving their [pointer] into the currently displayed submenu. Amazon uses this for a nice effect. As long as the [pointer] stays within that blue triangle the current submenu will stay open. It doesn’t matter if the [pointer] hovers over “Appstore for Android” momentarily – the user is probably heading toward “Learn more about Cloud Drive.”

And if the [pointer] goes outside of the blue triangle, they instantly switch the submenu, giving it a really responsive feel.

So if you’re as geeky as me and think something this trivial is cool, I made a jQuery plugin that fires events when detecting this sort of directional menu aiming: jQuery-menu-aim.

See the source link for more.

Interaction Media Features

While it’s still true that You Can’t Detect A Touchscreen, the Interaction Media Features media queries can come in handy in edge cases. Still, don’t assume too much about a device, as both the link above and the source for this emphasize.

Thanks to the W3C CSS Working Group and the CSS community, we have a cleaner solution.

On the Media Queries Level 4 Working Draft, there is a spec for Interaction Media Features that includes three definitions:

These provide the capability to query a document based on the presence and accuracy of the user’s pointing device and whether it has the ability to hover over elements.

Let’s take a closer look at each one:

Pointing Device Quality: The pointer Feature

The pointer media feature is used to query about the presence and accuracy of a pointing device such as a mouse. If a device has multiple input mechanisms, the pointer media feature must reflect the characteristics of the “primary” input mechanism, as determined by the user agent.” - W3C

The key word here is “accuracy” of the pointing device.

  • A mouse or a drawing stylus is very accurate and defines the value of fine.
  • A finger or a Kinect peripheral isn’t, and takes the value of coarse.

Therefore, we can adapt our UI elements to the user’s pointer capabilities. This is useful for making hit areas larger, if the user’s main input mechanism is a finger.

Code language: CSS

/* The primary input mechanism of the device includes a pointing device of limited accuracy. */
@media (pointer: coarse) { ... }
 
/* The primary input mechanism of the device includes an accurate pointing device. */
@media (pointer: fine) { ... }
 
/* The primary input mechanism of the device does not include a pointing device. */
@media (pointer: none) { ... }

An example use case for this query is to size the click area of a checkbox or radio.

Hover Capability: The hover Feature

The hover media feature is used to query the user’s ability to hover over elements on the page. If a device has multiple input mechanisms, the hover media feature must reflect the characteristics of the “primary” input mechanism, as determined by the user agent.” - W3C

It’s important to notice that it only evaluates the primary input mechanism. If the primary input mechanism is not able to hover, but the secondary input can, then the query will resolve to none:

For example, a touchscreen where a long press is treated as hovering would match hover: none.” - W3C

  • A touch screen device, where the primary pointer system is the finger and can’t hover, will take the value of none.
  • A device where the primary input is a mouse and can easily hover parts of the page takes the value of hover.

Code language: CSS

/* Primary input mechanism system can 
   hover over elements with ease */
@media (hover: hover) { ... }
 
/* Primary input mechanism cannot hover 
   at all or cannot conveniently hover 
   (e.g., many mobile devices emulate hovering
   when the user performs an inconvenient long tap), 
   or there is no primary pointing input mechanism */
@media (hover: none) { ... }

A good use of this query is a drop-down menu.

Rare Interaction Capabilities: The any-pointer and any-hover Features

On devices that are both touch and have a mouse or a stylus, like the Microsoft Surface, the hover and pointer media query will evaluate the primary input mechanism only.

As Andrea Giammarc pointed out, his Dell XPS 13” touch takes the value of fine, even though it does have a touch screen because the primary input mechanism is a mouse.

[…]

If we want a device like that to take the value of coarse or hover, we can use the Rare Interaction Capabilities.

The any-pointer and any-hover media features are identical to the pointer and hover media features, but they correspond to the union of capabilities of all the pointing devices available to the user. More than one of their values can match, if different pointing devices have different characteristics. They must only match none if all of the pointing devices would match none for the corresponding query, or there are no pointing devices at all.” - W3C

Code language: CSS

/* One or more available input mechanism(s) 
   can hover over elements with ease */
@media (any-hover: hover) { ... }
 
/* One or more available input mechanism(s) can hover, 
   but not easily (e.g., many mobile devices emulate 
   hovering when the user performs a long tap) */
@media (any-hover: on-demand) { ... }
 
/* One or more available input mechanism(s) cannot 
   hover (or there are no pointing input mechanisms) */
@media (any-hover: none) { ... }
 
 
/* At least one input mechanism of the device 
   includes a pointing device of limited accuracy. */
@media (any-pointer: coarse) { ... }
 
/* At least one input mechanism of the device 
   includes an accurate pointing device. */
@media (any-pointer: fine) { ... }
 
/* The device does not include any pointing device. */
@media (any-pointer: none) { ... }

Browser Support Isn’t Bad at All!

Even though this is a working draft, it has pretty good support.

My simple test proved successful on Chrome, Chrome for Android, Safari, Edge, Opera, Samsung browser, and Android Browser, but it didn’t work on [Firefox], Opera Mini or IE.

[…]

I think we are ready to use this feature, and as [Firefox] adds support for it and IE dies once and for all, we will have full support.