Matching ContactAddress fields to autofill attributes

[jcayzac]

Hi,

There is no clear mapping between the fields of PaymentAddress and the values accepted by the autocomplete attribute for shipping and billing addresses: PaymentAddress uses descriptive semantics while autocomplete leaves the semantics open to regional variations. Is there a suggested mapping between the two?

Thank you.

[ianbjacobs]

@marcoscaceres, @danyao, @rsolomakhin, @romandev, @aestes comments welcome!

[rsolomakhin]

From the top of my head:

PaymentAddress	Autocomplete
recipient	name
organization	organization
addressLine	street-address
dependentLocality	address-level3
city	address-level2
region	address-level1
country	country
postalCode	postal-code
sortingCode	postal-code
phone	tel

There's no separate field for sortingCode in autocomplete. The postal-code field is reused with a note:

Postal code, post code, ZIP code, CEDEX code (if CEDEX, append "CEDEX", and the arrondissement, if relevant, to the address-level2 field)

CEDEX is one type of sorting code. It may be the only type. I'm not 100% certain.

[jcayzac]

@rsolomakhin Thank you very much!

Maybe this could be mentioned in a non-normative section of the spec.

[jcayzac]

There's no separate field for sortingCode in autocomplete. The postal-code field is reused with a note:

Postal code, post code, ZIP code, CEDEX code (if CEDEX, append "CEDEX", and the arrondissement, if relevant, to the address-level2 field)

Just a small correction: the note actually says the address-level2 field is reused, not the postal-code field.

Thanks!

[mnoorenberghe]

As you said, autocomplete in the HTML spec varies by region so the mapping also varies by region. There isn't a single global mapping e.g. address-level1 could be a region or city, address-level2 could also be a (sub)-region or city, etc.

[jcayzac]

Yeah…

In the context of a PWA using the Payment Handler API, the address input may rely on web forms annotated with autocomplete=address-level3 etc…

Now, I am assuming that the reasoning behind fixing semantics in PaymentAddress is that since it is being consumed by a merchant it should not depend on either the locale of the end-user nor the region of the payment handler, which kind of makes sense. So, it's up to the payment handler to "standardize" the address and produce a locale-invariant one.

(That the Contact Picker API reuses PaymentAddress, OTOH, really doesn't make much sense to me to be honest. But I guess that's an issue for another working group 😉 )

[marcoscaceres]

Noting duplicate of w3c/payment-request#505.

[ianbjacobs]

This issue was raised in Payment Request, but closed once we removed addresses from that API. Since the features are now part of Contact Picker, we are transferring the issue here.