Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
martinLechnerShopify opened this issue Nov 11, 2024 · 10 comments
Open

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

martinLechnerShopify opened this issue Nov 11, 2024 · 10 comments

Comments

@martinLechnerShopify
Copy link
Collaborator

martinLechnerShopify commented Nov 11, 2024

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
Copy link

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
Copy link
Collaborator Author

martinLechnerShopify commented Nov 11, 2024

@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
Copy link

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
Copy link
Collaborator Author

@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
Copy link
Collaborator

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
Copy link

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

@theindra
Copy link
Collaborator

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
Copy link

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
Copy link
Collaborator Author

@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
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants