Three attributes for better web forms
Tags: html, inputs, inputmode, enterkeyhint
Published: 2023-06-12 15:27:13

---
title: Three attributes for better web forms
published: true
date: 2023-01-19 10:58:53 UTC
tags: html,inputs,inputmode,enterkeyhint
canonical_url: https://adactio.com/journal/19842
---

Forms on the web are an opportunity to make big improvements to the user experience with very little effort. The effort can be as little as sprinkling in a smattering of humble HTML attributes. But the result can be a turbo-charged experience for the user, allowing them to sail through their task.

This is particularly true on mobile devices where people have to fill in forms using a virtual keyboard. Any improvement you can make to their flow is worth investigating. But don’t worry: you don’t need to add a complex JavaScript library or write convoluted code. Well-written HTML will get you very far.

If you’re using the right `input type` value, you’re most of the way there. Browsers on mobile devices can use this value to infer which version of the virtual keyboard is best. So think beyond the plain `text` value, and use `search`, `email`, `url`, `tel`, or `number` when they’re appropriate.

But you can offer more hints to those browsers. Here are three attributes you can add to `input` elements. All three are enumerated values, which means they have a constrained vocabulary. You don’t need to have these vocabularies memorised. You can look them when you need to.

### `inputmode`

[The `inputmode` attribute](https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/inputmode) is the most direct hint you can give about the virtual keyboard you want. Some of the values are redundant if you’re already using an `input type` of `search`, `email`, `tel`, or `url`.

But there might be occasions where you want a keyboard optimised for numbers but the input should also accept other characters. In that case you can use an `input type` of `text` with an `inputmode` value of `numeric`. This also means you don’t get the spinner controls on desktop browsers that you’d normally get with an `input type` of `number`. It can be quite useful to supress the spinner controls for numbers that aren’t meant to be incremented.

If you combine `inputmode="numeric"` with `pattern="[0-9]"`, you’ll get a numeric keypad with no other characters.

The list of possible values for `inputmode` is `text`, `numeric`, `decimal`, `search`, `email`, `tel`, and `url`.

### `enterkeyhint`

Whereas the `inputmode` attribute provides a hint about which virtual keyboard to show, [the `enterkeyhint` attribute](https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/enterkeyhint) provides an additional hint about one specific key on that virtual keyboard: the <kbd>enter</kbd> key.

For search forms, you’ve got an `enterkeyhint` option of `search`, and for contact forms, you’ve got `send`.

The `enterkeyhint` only changes the labelling of the enter key. On some browsers that label is text. On others it’s an icon. But the attribute by itself doesn’t change the _functionality_. Even though there are `enterkeyhint` values of `previous` and `next`, by default the enter key will still submit the form. So those two values are less useful on long forms where the user is going from field to field, and more suitable for a series of short forms.

The list of possible values is `enter`, `done`, `next`, `previous`, `go`, `search`, and `send`.

### `autocomplete`

[The `autocomplete` attribute](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete) doesn’t have anything to do with the virtual keyboard. Instead it provides a hint to the browser about values that could pre-filled from the user’s browser profile.

Most browsers try to guess when they can they do this, but they don’t always get it right, which can be annoying. If you explicitly provide an `autocomplete` hint, browsers can confidently prefill the appropriate value.

Just think about how much time this can save your users!

There’s a `name` value you can use to get full names pre-filled. But if you have form fields for different parts of names—which [I wouldn’t recommend](https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/)—you’ve also got:

- `given-name`,
- `additional-name`,
- `family-name`,
- `nickname`,
- `honorific-prefix`, and
- `honorific-suffix`.

You might be tempted to use the `nickname` field for usernames, but no need; there’s a separate `username` value.

As with names, there’s a single `tel` value for telephone numbers, but also an array of sub-values if you’ve split telephone numbers up into separate fields:

- `tel-country-code`,
- `tel-national`,
- `tel-area-code`,
- `tel-local`, and
- `tel-extension`.

There’s a whole host of address-related values too:

- `street-address`,
- `address-line1`,
- `address-line2`, and
- `address-line3`, but also
- `address-level1`,
- `address-level2`,
- `address-level3`, and
- `address-level4`.

If you have an international audience, addresses can get very messy if you’re trying to split them into separate parts like this.

There’s also `postal-code` (that’s a ZIP code for Americans), but again, if you have an international audience, please don’t make this a required field. Not every country has postal codes.

Speaking of countries, you’ve got a `country-name` value, but also a `country` value for [the country’s ISO code](https://en.wikipedia.org/wiki/Country_code).

Remember, the `autocomplete` value is specifically for the details of the current user. If someone is filling in their own address, use `autocomplete`. But if someone has specified that, say, a billing address and a shipping address are different, that shipping address might not be the address associated with that person.

On the subject of billing, if your form accepts credit card details, _definitely_ use `autocomplete`. The values you’ll probably need are:

- `cc-name` for the cardholder,
- `cc-number` for the credit card number itself,
- `cc-exp` for the expiry date, and
- `cc-csc` for the security again.

Again, some of these values can be broken down further if you need them: `cc-exp-month` and `cc-exp-year` for the month and year of the expiry date, for example.

The `autocomplete` attribute is _really_ handy for log-in forms. Definitely use the values of `email` or `username` as appropriate.

If you’re using two-factor authentication, be sure to add an `autocomplete` value of `one-time-code` to your form field. That way, the browser can offer to prefill a value from a text message. That saves the user a lot of fiddly copying and pasting. [Phil Nash has more details on the Twilio blog](https://www.twilio.com/blog/html-attributes-two-factor-authentication-autocomplete).

Not every mobile browser offers this functionality, but that’s okay. This is classic progressive enhancement. Adding an `autocomplete` value won’t do any harm to a browser that doesn’t yet understand the value.

Use an `autocomplete` value of `current-password` for password fields in log-in forms. This is especially useful for password managers.

But if a user has logged in and is editing their profile to _change_ their password, use a value of `new-password`. This will prevent the browser from pre-filling that field with the existing password.

That goes for sign-up forms too: use `new-password`. With this hint, password managers can offer to automatically generate a secure password.

There you have it. Three little HTML attributes that can help users interact with your forms. All you have to do was type a few more characters in your `input` elements, and users automatically get a better experience.

This is a classic example of letting the browser do the hard work for you. As Andy puts it, [be the browser’s mentor, not its micromanager](https://buildexcellentwebsit.es/):

> Give the browser some solid rules and hints, then let it make the right decisions for the people that visit it, based on their device, connection quality and capabilities.