/dev/nikc/blog

Kuolleiden purjehduskenkien seura

Jan 29th 2013

Stop breaking your forms

20:13

A good form is invisible: it just works. In contrast, a broken form makes you want to pull your hair out, simply because it forces you to put your efforts into a side effect, not into what you're trying to accomplish.

Broken keyboard access

When I fill out a form I often submit it by hitting enter. I'm already using the keyboard, so that's the logical thing to do. Too often one of two scenarios occur:

  1. nothing at all happens, e.g. the form is not submitted
  2. the action I was attempting to do fails

The first scenario is related to broken markup; the inputs are not wrapped in a form element, so the browser can't possibly know where and how to submit the data. (Back in the days it could've simply been a missing submit-input, but browsers are nowadays less picky about that.)

The second scenario is harder to define, but most likely happens because the form handler listens to the wrong event and/or the form's action isn't directed to its proper handler.

If you fail at this, you should probably also read up on how to setup proper tab order.

Broken validation

Client side validation is useful. It saves me from the frustration of submitting a form, only to be presented with the same form again (hopefully with an added error message). In the worst case all the inputs are also left blank.

Using a modern browser, I find it lovely how it nowadays1 can fill out forms for me, e.g. shipping information in online stores. Just a few days ago, I made a purchase at a store where each approved input was flagged with a small green tick next to it. It didn't, however, manage to validate more than the first input, when my browser filled out the whole form at once. In the end, I was forced to tab through each input –leaving the contents untouched– to be able to submit the form and complete my purchase.

The reason for this is most likely lacking understanding of Javascript events. Instead of listening to (change) events on the containing form element, each input is observed separately, thus necessitating a focus and sometimes also the blur event to happen on each input separately.

Sadly, browser support for input validation isn't yet a complete replacement. However, you should use feature detection and revert to Javascript validation only when it's needed. (And when you do, you should make sure it works, not just that it works on my computer.)

Broken login

By far my biggest pet peeve is broken login forms, since I use them very often. Especially since the usefulness of the reason for breaking them is marginal at best; placeholder values.

It's far too common to populate the username input with the value "username" and the password with the value "password", and then leaving out actual labels to save space in the layout. That last sentence should already tell you you're doing something wrong, but at the very least the fact that password inputs don't display the default value as readable text should give you a hint.

The original intent might be benign, but when done wrong it breaks my password manager2, in the end actually causing me several extra steps to use the form, which is hardly a good outcome.

If you really want to use placeholders, use the placeholder attribute. It will work as you expect and already works in most browsers. If it isn't supported in a browser, it should hardly be considered a showstopper, as you're already describing the inputs with labels, aren't you.

1 IIRC, Netscape Navigator was able to do this, so it's hardly a novel feature.

2 I use 1Password, not my browser, to store my passwords.

Leave a comment

XHTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Meta

Pages

Search blog

Latest comments