Upon reading the draft Media Queries Level 4 (MQL4) specification I am most excited about the new interaction media features. The new media query specification gives us two new interaction media features which enable us to determine the type of input that a user is using, these are pointer and hover.

‘Pointer’ media feature

The pointer media feature allows you to test the type of pointer input that your user is using when accessing your site. The pointer media feature has three possible values:

  • none – specifies that the device does not include a pointing device
  • coarse – specifies that the devices primary input method is not precise/accurate, an example being a finger on a touch screen
  • fine – specifies that the devices primary input method is precise, an example being a mouse or trackpad.

The main use case for the pointer media feature is to allow us to adjust our layouts for where it might be hard to click on something.

Example of ‘pointer’ media feature

A good example of where we might want to adjust our layout based on the pointer media feature would be a checkbox which could be enlarged for inaccurate input methods. This could be achieved as follows:

input[type="checkbox"] {

@media (pointer:coarse) {
    input[type="checkbox"] {

‘Hover’ media feature

The hover media feature allows you to determine the users ability to hover over an element in the page. The hover media feature has three possible values:

  • none – specifies that the user is unable to hover or that they do not have a pointing device
  • on-demand – specifies that the user is able to perform a hover action, however not by simply hovering over an element. An example would be some mobile browsers requiring you to “long press” the element to trigger the hover action.
  • hover – specifies that the user is able to hover over elements in the page. This means that anything you specify using :hover can be triggered easily by a user.

While these three values provide us with flexibility in building our interfaces, I feel that it doesn’t provide a great user experience if the user is required to do a special action to trigger a hover. I think the most common use case will therefore be to target extra functionality to devices that trigger a hover normally.

Example of ‘hover’ media feature

It is common on desktop sites to be able hover over a menu and then be able to see the sub menu items hidden within.

Prior to the hover media feature this became difficult because we were unable to reliably determine whether the user would be able to hover or not (well without resorting to user agent sniffing, which we all know isn’t good). This lead to frameworks such as Twitter Bootstrap opting to change the action to a click to open a sub menu instead of hover.

The hover media feature allows us to start to apply this functionality only to devices that support hover. To do this we simply wrap the CSS related to this functionality with the a media query using the hover media feature.

@media (hover) {
    .menu-item {
        position: relative;

    .menu-item .subnav {

    .menu-item:hover .subnav {

Using the ‘pointer’ and ‘hover’ media features together

Having looked at both the pointer and hover media features independently we can start to look at how we can use them together. The table below is adapted from the MQL4 specification and shows the type of devices that falls into each type:

pointer media feature



hover media feature none smartphones, touch screen

stylus-based screens (Cintiq, Wacom, etc)


Nintendo Wii controller, Xbox Kinect, 

 mouse, touch pad

This table gives us an idea regarding the cross over we see between these media features and what sort of device they indicate out users are using.


Both the pointer media feature and the hover media feature have the potential to really benefit how we design our interfaces. They give us greater understanding of how our user is likely to interact with the page so we can optimise accordingly.

The full spec can be found over here http://dev.w3.org/csswg/mediaqueries-4/.

Are you looking for your next role?

I work as an Engineering Manager at Beamly where we are currently looking for both Frontend and Full Stack software engineers based in our London office.

Find out more