Let's stop customizing form fields

Posted on July 6, 2013

If you’re a web developer you’ve probably had experience customizing a form field. Not just tweaking the padding of a text input or adding a subtle border around a textarea, but something more custom.

A beautiful, custom drop down by Jonno Riekwel
A beautiful, [custom drop down](http://365psd.com/day/145/) by Jonno Riekwel

No environment changes as drastically and quickly as the web. Front-end web developers have far more at their disposal than they did five years ago.

But form fields have consistently been hard to customize. Why? Because these elements are tied so tightly to the browser and operating system. This makes customizing form fields extremely challenging.

Bending form fields to our will

If you Googled “custom select menu” you’d find a number of resources to change the way a select element is rendered. You’ll find jQuery plugins like Formalize, Chosen, Select2 and Uniform. These are really nice solutions. Developers have spent a tremendous amount of time to allow for field customization. But these customizations can lead to problems.

The problem with JavaScript form plugins

Cedric Dugas accurately states in How to style select, radio & checkbox form elements only with css, “[making] a javascript plugin [to] make a select element behave exactly like the native one is already hard.” Cedric mentions that JavaScript methods are tricky because:

  1. Replicating native field behavior per browser, per operating system and per device is exhausting and daunting
  2. These plugins add a great deal of “code bloat” to your site
  3. Will the user with JavaScript disabled be able to view or complete the form?

Using CSS to tweak form styling

Cedric suggests in his article to style form fields with just CSS. This is better because the experience is more native and doesn’t require JavaScript. But there are issues with this, too. The technique isn’t supported in all browsers.

Also, a couple users mentioned usability issues because of no :focus styles. A simple fix, but these are just two users using two browsers. There’s a much bigger internet out there.

Mo’ replacing, mo’ problems

No matter what method we use to replace form fields we run into a number of questions:

This is just the beginning of the complications. Form elements are all about capturing and controlling data. If a field isn’t usable the form is broken whether it looks custom or not.

It sounds like customizing form elements is leaving us running in place.

Let’s stop customizing form fields

Because there are millions of devices, operating systems, browsers and users let’s stop customizing these elements. To clarify, I don’t believe we should stop making our forms look nice. But we should be making clear and usable controls through native methods. Our desire to customize can create problems for our users:

  1. Load time: Let’s remove the time it takes to load a plugin (and even a full library) for customizing fields.
  2. Accessibility: Users are familiar with how form elements look and work on their devices. Let’s develop to their expectations.
  3. Priorities: Covering every use case for fields is an endless chore. Let’s stop playing catch-up with operating system and browser behavior and focus on making more usable forms.

If we want the ability to customize we need to start at the operating system and browser level like Paul Irish is proposing.

For all intents and purposes, let’s use native form elements until there’s a native way to customize them.

Google