Introduction

Autofill is a key feature of the web that reduces friction for millions of users everyday. It is widely used on login screens, e-commerce, and contact forms, to name a few examples.
At the same time, autofill on the web can be improved.
The API’s reliance on form fields and the autocomplete attribute effectively ties it to the site’s markup, making it hard for developers to build dynamic websites with flawless autofill experiences.

Autofilling addresses can be tricky when the form itself needs to change based on the autofilled values. The fields can change their order, new fields can be added or fields removed.
As an example, think of an address form that may or may not include a “state” field, based on the selected country. The site may not want to burden the user with this form field that they may not need, but would want to add it if and when it is necessary, and would want the browser to autofill that field if that’s the case.

To get around these limitations of HTML-based autofill, developers often rely on hidden form fields that enable them to collect such optional information and then surface it to the user if needed.

While that kinda works, it is a source of interoperability issues (as different browsers tend to do different things when it comes to such hidden fields), and it often results in a lot of developer pain.

Decoupling autofill data from HTML and the DOM

In the HTML spec, the autocomplete attribute fulfills two separate roles: the spec talks about the autofill expectation mantle vs. the anchor mantle. In short, we rely on input fields to represent both the information that users would expect the browser to fill, as well as the place in which the browser would fill it (and to an extent, the UI in which users interact with the autofill browser feature).
We think that it may make sense to create a separate path in which we can split apart those different roles.

As discussed above, in some cases, the information that we want from the browser’s autofill store can’t necessarily be mapped to a static set of input fields with autocomplete attributes.
Similarly, the information that developers want to get from the browser’s autofill may not be immediately mapped to the available input fields available in the DOM when autofill happens.

We have an explainer with a couple of spelled out options: an explicit autofill API, and a form-based event handler. We'd love feedback on either, or new ideas.

The TL;DR on the above is:

• There's a huge amount of complexity when handling autofill and addresses in a global context. The components of an address can drastically vary between contries.
• Sites need a way to ask the browser for the full address, and then create forms/presentations based on that, rather than the other way around, which is today's situation.
• We can do that based on the current form-based model, or can provide UI that would gives users better control of the data they share.

Feedback

Feedback on this thread would be highly appreciated!!