[whatwg] Improving autocomplete

Elliott Sprehn esprehn at gmail.com
Fri Oct 26 00:24:33 PDT 2012


Several of us on the Chrome team have been thinking about the
challenges of filling out long forms full of personal information.
We've noticed that site authors split up their forms across multiple
pages to avoid overwhelming their users with one single massive form
[1]. This is particularly bad on mobile where we've observed some
popular retailers splitting their forms into six or more pages in an
attempt to optimize their flow for a small screen. This unfortunately
defeats many of the advantages of existing browser autocomplete.

In researching this we’ve found that with a few changes built on the
existing HTML autocomplete spec [2] we can allow authors to recombine
their forms and enable browsers to provide more useful autocomplete.

1) HTMLFormElement.prototype.requestAutocomplete()
Asks the user agent to asynchronously present a UI for performing full
<form> autocomplete using the already spec’ed autocomplete attributes
[2] used in the form. In concept this is very similar to prompt()
except the UA could provide a streamlined experience for filling in
information in large chunks. For example you could imagine choosing a
shipping address from a drop down instead of presenting multiple
inputs.

2) Simple event named “autocomplete”
This event is dispatched on the form element after the UI presented by
requestAutocomplete() is closed if the form validates after having
filled each input and firing all necessary input events like “change”.

3) Simple event named “autocompletecancel”
This event is dispatched on the form if the UI is canceled.

Using this API authors may simplify their input flows from forms
spread over multiple pages to just a few clicks on a single page all
while getting all the autocomplete goodness! Authors can also display
no forms at all to users of a browser who implements this proposal for
one click checkout experiences which are important on mobile devices.

The proposed additions also improve security on the web as users will
become accustomed to inputting their sensitive data through an
unspoofable UI that could warn users of phishing sites or even allow
them to choose per domain security images.

We’d love to hear the thoughts of other implementers on this proposal. :)

[1] ex. Retailers often split forms into credit card, billing address,
and shipping address pages.
[2] http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#attr-fe-autocomplete

- E


More information about the whatwg mailing list