Interaction
Getting started with ... is a concise series introducing you to the practicalities of web development. You'll set up the tools you need to construct a simple webpage and publish your own simple code.
Small screen devices like mobile phones often have touchscreens. Large screen devices like laptops and desktop computers often come with hardware like a mouse or a trackpad. It’s tempting to equate small screens with touch and large screens with pointers.
But the reality is more nuanced. Some laptops have touch screen capabilities. Users can interact with either a touchscreen or a trackpad or both. Likewise it’s possible to use an external keyboard or mouse with a touchscreen device like a tablet.
Instead of trying to infer the input mechanism from screen size, use media features in CSS.
Pointer
You can test for three possible values with the pointer media feature: none, coarse, and fine.
If a browser reports a pointer value of none the user might be using a keyboard to interact with your website.
If a browser reports a pointer value of coarse it means the primary input mechanism isn’t very accurate. A finger on a touchscreen is a coarse pointer.
If a browser reports a pointer value of fine it means the primary input mechanism is capable of fine-grained control. A mouse or stylus is a fine pointer.
You can adjust the size of your interface elements to suit the pointer value. Try visiting this website in different kinds of devices to see how the interface adapts.
In this example, buttons are made larger for coarse pointers:
button {
padding: 0.5em 1em;
}
@media (pointer: coarse) {
button {
padding: 1em 2em;
}
}
It’s possible to also make elements smaller for fine pointers but be careful about doing this:
@media (pointer: fine) {
button {
padding: 0.25em 0.5em;
}
}
Even if someone has a primary input mechanism capable of fine-grained control, think twice before reducing the size of interactive elements. Fitts’s Law still applies. A smaller target requires more concentration even with a fine pointer. A larger target area benefits everyone regardless of pointing device.
Any pointer
The pointer media feature reports the fineness of the primary input mechanism. But many devices have more than one input mechanism. It’s possible that someone is interacting with your website using both a touchscreen and a mouse at the same time.
The any-pointer differs from the pointer media feature in that it reports if any pointing device passes the test.
An any-pointer value of none means that no pointing device is available.
An any-pointer value of coarse means that at least one pointing device is not very accurate. But that might not be the primary input mechanism.
An any-pointer value of fine means that at least one pointing device is capable of fine-grained control. But again, this might not be the primary input mechanism.
Because the any-pointer media query will report a positive result if any of the input mechanisms pass the test, it’s possible for a browser to report a result for any-pointer: fine and also report a result for any-pointer: coarse. In that case the order of your media queries matters. The last one will take precedence.
In this example, if the device has both a fine and a coarse input mechanism, the coarse styles are applied.
@media (any-pointer: fine) {
button {
padding: 0.5em 1em;
}
}
@media (any-pointer: coarse) {
button {
padding: 1em 2em;
}
}
Hover
The hover media feature reports on whether the primary input mechanism can hover over elements. This usually means there’s some kind of cursor on the screen being controlled by a mouse or a trackpad.
Unlike the pointer media feature which differentiates between fine and coarse pointers, the hover media feature is binary. If the primary input device is capable of hovering over elements it will report a value of hover. Otherwise the value is none.
In this example, some supplementary icon is available on hover but only if the primary input device is capable of hovering over an element.
button .extra {
visibility: visible;
}
@media (hover: hover) {
button .extra {
visibility: hidden;
}
button:hover .extra {
visibility: visible;
}
}
If you use your mouse to hover over that button, the icon will appear. But if you use your keyboard to tab to the button, the icon remains invisible. When you use the keyboard, you’re focusing rather than hovering. A desktop device with a mouse attached will report that the primary input mechanism is capable of hovering, which is true. But anyone using a keyboard while a mouse is attached won’t get the benefit of the :hover styles. So it’s a good idea to combine :hover and :focus styles to cover both interactions.
button .extra {
visibility: visible;
}
@media (hover: hover) {
button .extra {
visibility: hidden;
}
button:is(:hover, :focus) .extra {
visibility: visible;
}
}
Even if the primary input device is capable of hovering over elements, be careful about hiding information behind a hover interaction. The information becomes less discoverable. Don’t use hover to hide important information or an important interface element.
Any hover
The hover media query only reports on the primary input mechanism. Some devices have multiple input mechanisms: touchscreen, mouse, keyboard, trackpad.
Just as any-pointer reports on any of the input mechanisms, any-hover will be true if any of the available input mechanisms are capable of hovering over elements.
If you decided to reverse the logic in the previous example, you could make the hover styles the default and then remove them if any-hover has a value of none.
button .extra {
visibility: hidden;
}
button:hover .extra,
button:focus .extra {
visibility: visible;
}
@media (any-hover: none) {
button .extra {
visibility: visible;
}
}
On a device that has no input mechanism capable of hovering, the extra icon is always visible.
Virtual keyboards
People use cursors and fingers to explore interfaces but when it comes time to enter information, they need a keyboard. That’s fine if there’s a physical keyboard attached to their device, but if they’re using a touchscreen device it’s a little more complicated. These devices provide on-screen virtual keyboards.
Input types
Unlike a physical keyboard, virtual keyboards can be tailored to match the expected input. If you provide information about the expected input, devices can serve up the most appropriate virtual keyboard.
HTML5 input types are a great way of describing your input elements. The type attribute accepts values such as email, number, tel, url, and more.
<label for="email">Email</label>
<input type="email" id="email">
<label for="number">Number</label>
<input type="number" id="number">
<label for="tel">Tel</label>
<input type="tel" id="tel">
<label for="url">URL</label>
<input type="url" id="url">
Input modes
The inputmode attribute gives you fine-grained control over virtual keyboards. For example, whereas there’s one input type with a value of number, you can use the inputmode attribute to differentiate between whole numbers and decimals.
If you’re asking for a whole number, like somebody’s age, use inputmode="numeric".
<label for="age">Age</label>
<input type="number" id="age" inputmode="numeric">
If you’re asking for a number that includes decimal places, like a price, use inputmode="decimal".
<label for="price">Price</label>
<input type="number" id="price" inputmode="decimal">
Autocomplete