A List Apart

Menu
The A List Apart Blog Presents:

On Styled Form Elements

by · · 12 Comments

Article Continues Below

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 submit, reset, image, and plain old button.

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.

As the web moved forward, though, we grew hungry for better interfaces. We built JavaScript-driven components on top of these basic input fields to achieve better experiences, and that worked fine for a while, up until everything changed when the modern mobile environment exploded in 2007.

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.

The Various Dropdown Interfaces of Apple Devices

Android’s drop-down interface was similar, but ever so slightly different—a modal listing of options which closes on selection.

Android’s Native Dropdown Interface

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.

The iOS Date picker

Standard 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 date and 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.

About the Author

12 Reader Comments

Load Comments