Documentation
¶
Overview ¶
Command autocomplete adds autocomplete tokens to form fields whose purpose the markup makes plain.
<input type="email" name="email"> -> … autocomplete="email" <input name="postcode"> … autocomplete="postal-code"
A token is a promise about what a field means, and a browser and a password manager both act on it: the wrong token fills a card number into a phone box. So the rule here is that the evidence has to be unambiguous, and where it is not the field is left alone and counted. A page that gets nothing from this program is a page whose markup says nothing, which is a fact worth reporting rather than papering over.
One token cannot be decided from the field at all. A password field is "current-password" in a sign-in form and "new-password" in a registration or a change-password form, and getting it backwards is not cosmetic: it makes a password manager offer to fill a new-password field with the old password, or offer to save a login form's field as a new one. The evidence for which is the form - how many password fields it has, and what its action says - and that is a third granularity for these programs:
examples/gip/dir a decision per element, from its own text examples/gip/landmarks one decision about the whole document this a decision per form, from the form's other fields
So the first pass groups the fields by the form they are in and decides per form, and the second pass writes. A field outside any form is its own group, because a form-less field is what a single-field widget looks like.
What it will not do. It never replaces an autocomplete a document already has, including autocomplete="off": a page that turned it off may be wrong about that, and it is not this program's decision. It adds nothing to a hidden field, a button, a checkbox, a radio, a file or a colour picker, none of which autofill. And it will not guess a cc-* token from a name that only might mean a card, because a wrong card token is the worst outcome on the list.