For almost 20 years, we’ve had the same input types and form elements we still use today: text fields and areas, password fields, select dropdowns, radio buttons, checkboxes, file fields, hidden fields, and the menagerie of button types including
image, and plain old
All of these input types brought with them some styles and functions from both the operating system and browser in use. Much to our own chagrin, we (mostly) figured out how to fight that to achieve custom styles for basic and advanced elements.
Custom styling usually meant background images, pseudo-classes, weird vendor prefixes, and selectively hiding certain elements. I’m not going to get into the accessibility concerns of styling inputs with those tactics (this post can only be so long), but the complexity of input types and their implementation amplified cross-browser and platform issues. Each possible combination of browser and operating system brings its own styles and functions, some of which are hard to control, and all of which are inconsistent.
Even with that amount of stylistic complexity, the interactions of these early input types were pretty simple—click this, type into that box, check the other thing. Simplistic interaction allowed us to get a little crazy with custom styles without hurting the experience. Only the select dropdown, with its list of options, had a more advanced interaction.
The changing environment led to changing interactions—our adorable little calendar-like date picker was an absolute nightmare to use on a 3.5-inch touchscreen, and even dropdowns needed to be rethought.
The iPhone’s native drop-down control was a full-screen wheel-type interface, which was a much more natural interaction at its size. It’s not the perfect interface, especially when the number of options exceeds ten or so (don’t get me started on a listing of countries), but it was a big improvement over fiddling with a tiny, in-page drop-down list.
Android’s drop-down interface was similar, but ever so slightly different—a modal listing of options which closes on selection.
There was a native date picker in iOS—a three-segment drop-down interface, which was much better to use than its calendar-based predecessor.
select elements were well-supported on these new devices, but we didn’t have a way to leverage other built-in, native components, like the iOS date picker, on the web. Luckily, HTML5 came along and brought us some fantastic new input types. Types like
range set the stage for browsers and operating systems to begin handling more and more complex interactions. Apple quickly introduced support for
date in iOS 5, and gave us the ability to expose the native iOS date picker in the browser.
As support for these new input types grows, we can begin implementing them today with fallbacks when appropriate (or at least helpful hints, since unsupported input types become text fields). Dropdowns and date pickers are just a sampling of the things that are better handled by systems themselves—a device will always be able to make better decisions about its use than the device-agnostic web.
The simplistic interactions of early input types gave us room to experiment, but the more complex interactions of modern fields leave little room for that. There’s only so much we can control before the browser and operating system take over, and then we’re at their whim. The web isn’t stopping any time soon—we’re headed for more complex input types with even less control exposed.
That makes me wonder how much longer we’ll be fighting to style these elements. It’s time we stop breaking and faking input types and accept the ebb and flow of things.