Improving address autofill

[yoavweiss]

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!!

[battre]

I am excited to explore this. I have left some comments on the document.

[Crissov]

Sites need a way to ask the browser for the full address,

That seems like a privacy hazard.

[yoavweiss]

That seems like a privacy hazard.

Sites can already do that through autofill, it's just slightly more complex. Introducing more explicit mechanisms can also provide us affordances to improve the privacy situation and make sure that users are in the loop and aware of the data that is being shared.

[theindra]

The support for autofilling hidden fields is already a big privacy concern but due to lack of alternatives still traded off to make many of the flows used on the web work.

[rsolomakhin]

I'm supportive of this proposal in general. I will add some minor comments in the explainer doc.

[yoavweiss]

The repo now lives at https://github.com/WICG/proposals/issues/162

Let's continue the discussion there!! :)

[battre]

Yoav, I think that you shared the wrong link. This issue is #162.

[yoavweiss]

Indeed.. The repo is at https://github.com/WICG/address_autofill_api/

[Crissov]

Although it is something quite different, I’m wondering whether #115 could (partially) be solved with the same approach used to solve this issue, whatever that will end up looking like. In both cases, primarily e-commerce sites want to know information about their customer that may be stored in their browser, in order to enhance their (shopping) experience (and thereby improve conversions).