Four Truths About Input

Written by Jason Grigsby on

Here are four truths about input that have changed the way I look at the web.

1. Input is exploding

The last decade has seen an explosion of new types of input. The pace of input innovation is like nothing we’ve seen before.

The mouse gained mass market adoption a full 142 years after the adoption of the keyboard. It took twelve more years before Microsoft popularized the scroll wheel mouse. Nine more years after the scroll wheel before cameras were commonplace in our computers and phones.

History of computer input as told through the lens of Apple devices. The same timeline could use Windows or Android. What matters is the decreasing time between new forms of input.

Since the iPhone’s release in 2007, every year has brought us new sensors and other forms of input. Our current generation of phones contain everything from barometers to fingerprint sensors.

iPhone 6S sensors: Touch, 3D Touch, Fingerprint sensor, Camera (video and image), GPS (location), Compass, Bluetooth LE, Audio (Siri), Gyroscope, Accelerometer, Barometer, Proximity sensor, Ambient light sensor, NFC (Apple Pay), iBeacon

The iPhone 6S and all of its sensors

2. Input is a continuum

Much like the web never had a fixed viewport size, input was never tied to a specific form factor. From the earliest days, smartphones have had keyboards and pointers. Even iPhones and iPad, which we normally don’t think of as having different types of input, support bluetooth keyboards and stylus.

In the last few years, we’ve seen Windows devices that defy classification. Are they tablets or laptop computers? It depends on how they are used.

Laptops or tablets?

Are these Windows devices laptops or tablets?

Desktop computers now come with touch screens. And phones like the Nokia Lumia 950 can act as a desktop computer when docked to a monitor. We are truly designing for a continuum not only of screen sizes, but of input as well.

We can no longer make assumptions about input based on screen size or form factor. And frankly, we never should have.

3. Input is undetectable

Designing a tailored user experience for a keyboard and mouse is different than designing one for touch. It is tempting to try to detect whether a touch screen is present and then modify our designs accordingly.

Unfortunately, “it currently isn’t possible to reliably detect whether or not the current device has a touch screen, from within the browser.”

This isn’t unique to touch screens. You cannot reliably detect the presence of a physical keyboard or a mouse from within the browser either. And for various privacy and philosophical reasons, browser makers want to make sure that input remains undetectable.

Input is like Schrödinger’s cat. There is an infinite number of types of input until the moment that someone presses a mouse or touches a screen and we
observe that activity.

We cannot know in advance what types of input someone has access to. We can only detect input when it is used and that’s too late for our user interfaces.

4. Input is transient

One moment, someone could be sitting at a desk with their tablet connected to an external keyboard, mouse and display. The next moment, they could be using the touch screen exclusively.

Unlike Schrödinger’s cat, our input experiments don’t end. Knowing what input is used one moment tells you nothing about what will be used next.

Never miss an article!

Get Weekly Digests


If I may be so bold, I'll link to my touch/pointer events slides and, as an aside, point out that Pointer Events Level 2 are about to hit official W3C First Public Working Draft (though the editor's draft has been public for quite some time already at

Now if only we could convince Apple to also adopt them (noting that Chrome are now shipping their flavor, closely linked to the Level 2 spec, behind their experimental web platform flag right now, with the full stable release expected in Autumn)

Patrick H. Lauke


Do we really need to convince Apple, in this instance? jQuery maintains the Pointer Events Polyfill. Once we get to the point where PE is supported “everywhere but WebKit”, the polyfill should suffice (it’s only ~5 KB minzipped).

This is why CSS Media 4 add media queries like (pointer: coarse) and (hover: none) to detect primary input capabilities

Memmie Lenglet


I like the fact that CSS Level 4 tries to address these issues, but the whole idea of a "primary" input seems like a fallacy to me. The more I look at the MQs in Level 4, the more I find them to be misleading or potentially problematic.

FWIW, Stephanie Rieger's talk at Responsive Day Out does a great job examining the potential problems with them. There is a podcast of the talk available.

Let’s discuss your project! Email Us