[whatwg] Supporting more address levels in autocomplete

[Evan Stade]

(Trying again from alternate email address; apologies if this message shows
up twice.) Regarding UK addresses, libaddressinput[1], which is used by
Google for various products, currently accepts two levels of administrative
region for GB: city and optional county.

> This would be the first open-ended field name. Do we really want to make
> this open-ended? What happens if a form has n=1..3, and another has
> n=2..4? What if one has n=1, n=2, and n=4, but not n=3?

I don't know why a web author would do this, but n=m doesn't require n=m-1
or n=m+1 to be present. n=2..4 would just mean the site didn't get the n=1
value.

> How does a site know how many levels to offer?

It offers as many as it knows what to do with. It probably wouldn't know
what to do with n=5, or n=100, and it's highly unlikely a user agent would
return a value for those levels anyway, so practically speaking, n=1 to n=3
should be sufficient for now (although n=4 seems possible in the near
future). But I don't see the purpose in setting a limit in the spec.

> What should a Chinese user interacting with a US company put in as their
> address, if they want something shipped to China?

They would put in the same address regardless of the nationality of the
company, assuming the company is able to properly handle their address.
Which inputs are visible to the user should depend on which country they're
entering. This means that if a user changes the country, the inputs shuffle
around and hide or show. (requestAutocomplete places the onus of
understanding all this on the user agent, but there are javascript
implementations out there.)

> So they would be synonyms? Or separate fields?

They are pseudo-synonyms. In the US, "region" aligns with
"address-level-1", and either one would return the same value. In the UAE,
where there are cities but no higher level administrative region,
"locality" aligns with "address-level-1". In China, "address-level-1" is a
province a province-level city such as Beijing. Beijing is also "region",
confusingly, and a district of the city is a "locality".

So generally speaking, if I ship to both China and the US, I would create a
form with "address-level-[1..4]" and if the user starts to enter a US
address, only show the first 2 levels. If the user starts to enter a
Chinese address, show more levels. If using requestAutocomplete, all the
inputs are hidden all the time anyway.

If I am making a site that ships to just the US, I'd probably go with the
more intuitive "region" and "locality" and ignore address-level-n.

> Forms that require the user to split his address to small pieces may
> have their reasons. But if you just want to have an address to send
> stuff to, then all you need is a working postal address. A textarea
> with, say, name="postal", if used on different pages, would then let the
> user enter his entire address very simply, after just once typing it.

I agree with this, and plan to propose it separately from the proposal
currently under discussion. It might be hard to parse a working address out
of a free-form input, but the other direction is doable enough: creating a
block of text suitable to printing on an envelope given tokenized values.
This tackles the problem of how to format an autocompleted address for a
particular country and UI language (i.e. in the user agent has to know how
to do it, but the website doesn't).

-- Evan Stade

[1] https://code.google.com/p/libaddressinput/