On Styled Form Elements

by Anthony Colangelo

12 Reader Comments

Back to the Post
  1. 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.
    Copy & paste the code below to embed this comment.
  2. 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.
    Copy & paste the code below to embed this comment.
  3. 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.
    Copy & paste the code below to embed this comment.
  4. @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.
    Copy & paste the code below to embed this comment.
  5. Anthony, what are some good resources re: accessibility issues with customized form elements?
    Copy & paste the code below to embed this comment.
  6. @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.
    Copy & paste the code below to embed this comment.
  7. god.. the times when i spent so much hours creating a vanilla JavaScript datepicker.
    It.
    Was.
    Horrible. Was pretty proud of myself afterwards though.
    Copy & paste the code below to embed this comment.
  8. 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
    Copy & paste the code below to embed this comment.
  9. RWD changed styling forms and related tasks completely :)
    Copy & paste the code below to embed this comment.
  10. 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.
    Copy & paste the code below to embed this comment.
  11. 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.
    Copy & paste the code below to embed this comment.
  12. 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.
    Copy & paste the code below to embed this comment.