vocab.design

pattern · auth · forms

Autofill

also called browser autofill (community), form autofill (community), autofill suggestions (community)

The browser filling a form from values it has already saved, on its own or from a dropdown of the reader's own profile, so a field arrives answered.

Every browser keeps a profile: a name, one or two addresses, a phone number, some cards. Autofill is what it does with them. The reader puts the caret in a field and the user agent offers the values it holds, usually as a dropdown drawn above the page in the browser’s own chrome, and one pick writes every field the profile can answer at once. The page is not consulted, the page is not asked, and the page frequently does not know it has happened until it reads the values back.

What decides whether the fill is any good is the markup underneath it. A field that declares its input purpose gets the right value; a field that declares nothing gets a guess from its label, its name attribute and its neighbours, which is right often enough to be trusted and wrong often enough to be a problem. Two nearby patterns are not this one: address autocomplete is a lookup service the page itself calls, suggesting addresses the reader has never entered, and inline autocomplete completes what is being typed inside the field. Autofill answers from the reader’s own store, and its value arrives whole.

Three consequences the design has to absorb. The user agent paints the filled field itself, a pale tint plus its own dropdown, and it refuses nearly all of your styling: :autofill matches the state but the properties it will honour are a short list that has never included plain background-color, so a filled field will not match your theme and there is no supported way to make it. A filled value can be far longer than anything you designed the field for, since it comes from a real person’s real address rather than from your placeholder copy, so a field that clips or a row that reflows at thirty characters is a bug that only the reader with a long name ever sees. And the fill can land without the keystrokes a page listens for, so validation wired to keyup and a floating label wired to typing both miss it: watch change, and check the field’s value on submit rather than trusting your own event log.

Two habits worth keeping. autocomplete="off" has not stopped a password manager for years and no longer reliably stops the browser either, because refusing to fill a login form was read as hostile to the people who need filling most: state the purpose honestly and let the fill happen. And never lean on placeholder as label in a form the browser will fill, because the moment a value arrives the placeholder goes and the field is left unnamed. Getting this right is the cheapest defence a checkout has against redundant entry: typing is expensive for anyone using a switch, voice input, or an on-screen keyboard, and autofill is the browser offering to skip it.

Which word?

If you wantsay
the browser answers the field before the reader doesautofill
typing a postcode fills in the whole addressaddress autocomplete
the field finishes your word inside the fieldinline autocomplete

Related

See also: Input purpose · Redundant entry

Sources