Do we need full-address or can we live without?

[martinLechnerShopify]

The current public proposal suggests to introduce a new autofill token full-address to indicate that the browser should provide a structured address object that the developer can process and use to modify the underlying form.

A question to solve is if we will actually need this new token, or if we can define the API in a way that this is not necessary anymore.

If reusing the existing tokens today, once the browser triggers the autofill selector (i.e. indicating to the user which autofill entity to use), it could just forward all address fields (or a heuristic selection of fields based on the underlying form) that are associated with the autofill selection to the JS callback. Something like (rough sketch):
onautofill(mapOfAllAutofillValuesOfTheSelection, theElementTriggeringAutofill)

Are there any concerns with using this approach?

cc @yoavweiss @theindra @rsolomakhin @battre

[rsolomakhin]

Hi Martin,

It's a bit hard to understand the the approach that you're suggesting here. Is that described in the current public proposal? If not, please update the current public proposal, so we can review it again and go from there.

Sounds OK?

Cheers,
Rouslan

[martinLechnerShopify]

@rsolomakhin I didn't update the proposal yet, because I wanted to align first.

Essentially we have the following 2 options IMHO:

1. Introduce full-address as an autofill token as per the public specification (details in the proposal).
2. Slightly changing the public proposal to avoid introducing full-address as a token, and instead relying on the autofill tokens we have currently (address-line-1, -2, streetname etc.). When the browser triggers the autofill selector on one of these form elements and the user selects an entry to use for autofill, the browser provides all elements associated with the selected element to the JS API.

The essential question here is: can we live without having to specify yet another autofill property?

Does this clarify the options, or is it still too ambiguous? :-)

[rsolomakhin]

Is this the difference?

• Option 1: <form onautofill="autofillhandler" autocomplete="full-address" >
• Option 2: <form onautofill="autofillhandler">

If so, then Option 2 should be sufficient, IMHO.

If I misunderstood your question, please let me know! :-)

[martinLechnerShopify]

@rsolomakhin yes I believe HTML-wise this would be the difference :-) I was thinking similarly to you it seems - full-address doesn't bring any benefit - but wanted to double-check if I didnb't forget or overlook anything.
@yoavweiss @theindra just in case you feel differently, let's discuss, or otherwise I'll remove full-address from the proposal.

[theindra]

The reason why you think full-address doesn't add any value is because we adapted the proposal to not share the address in the onautofill-handler but share it only through the form, which will be updated in this new 2-stage process.
So to achieve full-address sharing it would work like this:

1. autofill triggers
2. current form is filled
3. handler triggers and update the form (shows new fields)
4. autofill runs again and fills the new fields

Correct?

[rsolomakhin]

Yep, that's pretty much it, @theindra!

[theindra]

I think it makes sense to remove full-address then.

Another question: Are there countries where the shape of the address form depends on something other than the country? E.g. the region or city?
If so, we might need to change the 2-stage process to an n-stage process. Think about it, if the browser has more address data than available fields it keeps iterating and calling the handler until the form is stable and doesn't change anymore.

What do you think? Maybe I'm overthinking it.

[rsolomakhin]

Are there countries where the shape of the address form depends on something other than the country? E.g. the region or city?

Does anyone in Shopify have this information? If we can limit N to some small number (e.g., 2), we will have easier time.

[martinLechnerShopify]

@theindra I think we should have this possibility in the back of our heads, but I wouldn't focus too much on it yet due to how often I expect this scenario to be reality (close to 0, if not 0).
If we need to, we could e.g. say in the spec the JS event will fire whenever the browser detects a change in the underlying form after the previous JS event (indicating the developer reacted to the autofill handler).

I'd focus on getting it right for the majority of cases for now.

[theindra]

Does anyone in Shopify have this information?
I asked around but I couldn't get a definitive answer. There for sure countries where some of the provided address format depends on things like region or city. But it's unclear if this should manifest in a different form structure or if it customary to have a form with all fields anyways.

I'd focus on getting it right for the majority of cases for now.
Yes, I agree. Let's focus on what we know. Nothing here seems to be a one-way door and we can easily extend it later as we learn.

[igrigorik]

I think there is still merit and advantage to full-address:

• onautofill would be a huge DX win — please! However, event and opt-in of what data is provided are distinct.
• full-address provides explicit opt-in for new behavior: if you only need zip-code to estimate shipping, the browser doesn't need to emit the whole shipping address.
• It mirrors an existing pattern for name which is a union of honorific-prefix, given-name, additional-name, etc. I think MDN explainer for name works verbatim for full-address, just replace name with address..

Using name rather than breaking the name down into its components is generally preferred because it avoids dealing with the wide diversity of human names and how they are structured; however, you can use the following autocomplete values if you do need to break the name down into its components...

[rsolomakhin]

SGTM, let's go with full-address. Are there any more open questions to resolve, or should we move on to the next steps in this direction?