-
Notifications
You must be signed in to change notification settings - Fork 2
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
Comments
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, |
@rsolomakhin I didn't update the proposal yet, because I wanted to align first. Essentially we have the following 2 options IMHO:
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? :-) |
Is this the difference?
If so, then If I misunderstood your question, please let me know! :-) |
@rsolomakhin yes I believe HTML-wise this would be the difference :-) I was thinking similarly to you it seems - |
The reason why you think
Correct? |
Yep, that's pretty much it, @theindra! |
I think it makes sense to remove 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? What do you think? Maybe I'm overthinking it. |
Does anyone in Shopify have this information? If we can limit N to some small number (e.g., 2), we will have easier time. |
@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). I'd focus on getting it right for the majority of cases for now. |
|
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
The text was updated successfully, but these errors were encountered: