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.
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.
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.
Ah, the date picker. Actually, it’s still a nightmare.
The problem is that when supported by desktop browsers, it stylistically sucks, while it’s decent and functional on mobile. In both cases, it probably has little to do with the page’s style.
It’s always been the same for select dropdowns, actually. But they *can* be stylized with some success, while you can’t do anything for native date pickers (except in Chrome).
A hard life for web designers.
Ah, the date picker. Actually, it’s still a nightmare.
The problem is that when supported by desktop browsers, it’s stylistically terrible, while it’s decent and functional on mobile. In both cases, it probably has little to do with the page’s style.
It’s always been the same for select dropdowns, actually. But they *can* be stylized with some success, while you can’t do anything for native date pickers (except in Chrome).
A hard life for web designers.
But the iOS date picker is a usability nightmare. For one, the user is unable to see the day of the week. Is it Wednesday, Saturday, a weekday, or weekend. How does a developer show a user blocked out days?
Though I like to enter a date in a text field where you can type something like “next tue” that still doesn’t give the user a visual representation of blocked out dates.
There’s a reason why we use styling of form elements. It can be a way to help make forms more usable for those that can see. It shouldn’t just to be for aesthetics, but also to improve usability.
Just as any chef knows, food should not only taste good, but also be pleasing to the eye. Our job as developers is to not only make forms more usable (email address fields come to mind), but to also work with designers to make forms more pleasing to the eye.
@Tanny: I definitely agree that things need to look great, but that can’t compromise the usability and accessibility of the actual controls of form elements.
It’s a tricky balance, but the sustainable path forward seems to be to accept (and make use of) what browsers and operating systems are doing to make things a better experience for their users.
Anthony, what are some good resources re: accessibility issues with customized form elements?
@MaxArt agreed. The Datepicker is legitimately one of the most needlessly complex UI widgets someone could ever encounter. It’s not just in web, either. Different paradigms across mobile, web, and desktop only compound the complexity.
god.. the times when i spent so much hours creating a vanilla JavaScript datepicker.
It.
Was.
Horrible.
Was pretty proud of myself afterwards though.
To answer Violet’s question, Simply Accessible has some great posts about specific form elements and how to keep them accessible:
http://simplyaccessible.com/?s=forms
RWD changed styling forms and related tasks completely 🙂
You make a good case for accepting the defaults, but not accepting them is how we have improved things over those 20 years.
One specific example is the select element. The experience is bad by default and many people use JS to fix it. If you compare the two experiences on the Chosen demo site http://harvesthq.github.io/chosen, I’d be surprised that people would choose the default experience as better. By default in all selects, you should be able to scroll or search. It’s a better experience and we only know that by improving something that we don’t accept.
This means that we need to keep using it, show use cases to browser makers, and push to have this element begin with a better default. We can neither decide that accepting browser defaults or always overriding them is the best answer. We need to iterate on experiences and share our results with the people that can affect positive change.
It’s an argument of who needs to let go of “control”. Do designers accept the way form elements natively look/work? Or do those who create the elements, and the “styling access” to them, need to accept that designers want more control?
What do all these JavaScript “fakes” tell us in real terms about what designer’s want? They have been around for years. Is it that all those who create them and use them are thinking incorrectly? Or do we take from this that there must be a need. If there wasn’t a problem then they wouldn’t be so many solutions out there. There’s a level of acceptance of that fact, surely?
For me it is a no-brainer. If I spend time creating a design that uses set spacing and colours and compositional treatment – considerations that help re-enforce a brand and also a consistent experience for the user – I want to be able to make those considerations on ALL the things on page.
I don’t mind the core functionality of an element being a set standard, but if someone is inside _my_ shop, and they wish to select something from _my_ list, I want that experience to re-enforce where they are, without that whisper of “your browser is X your browser is X your browser is X”.
The way I have designed my navigation has no browser UI influence, the fonts I have chosen have no browser influence, why should how my form looks have this visual stamp of browser identity? Designers are supposed to be given control. It is what we do. That is what needs accepting, imo.
I used to believe that as a designer, I should have complete say as to how everything on the page was presented, including the form elements, but over the past couple of years, I’ve come to adopt what I would consider a more responsive approach.
There’s a reason OS manufacturers have designed the inputs a certain way, and I would rather err on the side of user familiarity than give the user something that might confuse him/her even more.
Granted, there have certainly been use cases of form element redesigns improving UX (the select input, we can all agree, is notoriously terrible for any great amount of data), but for the most part, the user has already chosen what they want by the purchase of their device. I think I as the designer should respect that.
I have gained some new and valuable knowledge from it. Thanks again