[whatwg] Supporting more address levels in autocomplete

[Evan Stade]

On Tue, Mar 4, 2014 at 12:18 PM, Ian Hickson <ian at hixie.ch> wrote:

>
> On Mon, 3 Mar 2014, Evan Stade wrote:
> > > >
> > > > I don't think you can just write a stack of inputs that accepts
> > > > input for any country. The country determines:
> > > >
> > > > a) what fields make sense
> > > > b) what fields are required
> > > > c) the order of fields
> > > >
> > > > You could ignore (a) and settle for a crappy UI that shows all
> > > > fields that make sense anywhere in the world, but you'd still be
> > > > left with solving (b) and (c).
> > >
> > > (b) is an easy-to-solve problem: you don't make any of them required,
> > > and if the customer entered insufficient fields, they're not getting
> > > their package, and will have to be contacted out-of-band.
> >
> > I don't think the additional load that would place on customer service,
> > the number of missing packages, etc., would be considered an "easy"
> > problem or even an improvement over whatever they currently have in
> > place.
>
> I am not convinced it'd be that big a load (users generally know what
> parts of their addresses are required!). But in any case, if we're talking
> about mom-and-pop stores with a minimal load of international orders in
> the first place, it's likely that the customer service load would be
> pretty minimal.
>

Then why do so many sites bother to validate data as users input it?


>
>
> > > Can you elaborate on (c)?
> >
> > US looks like:
> >
> > Recipient
> > Organization
> > Street address
> > City, State ZIP
> >
> > Japan looks like:
> >
> > 〒 ZIP
> > State City
> > Street address
> > Organization
> > Recipient
>
> Ah, interesting. That is indeed a significantly larger difference than I
> expected.
>
> Can you elaborate on these? Where would "address-line2" and
> "address-line3" go? Where would "country-name" go?
>

Country name is always at the end. When I put "street address" above, I
meant it in the sense of "all the lines of street address". Different
countries have a different number of lines, but by definition they're
always all next to each other --- the definition of address-line-N is "the
Nth line of the street address when it's formatted for display".


>
>
> If the layout difference is that great, we should seriously consider
> documenting that also.
>

I think it's outside the scope of the autocomplete spec, but there are
libraries which to do this, such as libaddressinput, which provides a
service to get formatting data for various coutnries. For example, the
"fmt" portion of [1] tells you how to format US addresses. Chrome
integrates libaddressinput into requestAutocomplete so web authors get this
for free, but they could also use the service on their own if they didn't
want to rely on requestAutocomplete.

[1] https://i18napis.appspot.com/ssl-address/data/US


>
>
> Looking at the suggestions I listed earlier:
>
> > >    "address-line1" |
> > >    "address-line2" |- "street-address"
> > >    "address-line3" |
> > >    "address-line5"
> > >    "address-line6"
> > >    "address-line7" / "locality"
> > >    "address-line8" / "region"
> > >    "address-line9" / "country-name"
>
> This presumably wouldn't work sanely for Japanese addresses.
>
>
> > > Or we could do:
> > >
> > >    "address-line1" |
> > >    "address-line2" |- "street-address"
> > >    "address-line3" |
> > >    "subsublocality"
> > >    "sublocality"
> > >    "locality"
> > >    "region"
> > >    "country-name"
>
> This could work. It avoids the synonym problem.
>

Yes, this alternative works, but in my opinion is not preferable.


>
>
> > >    "address-line1" |
> > >    "address-line2" |- "street-address"
> > >    "address-line3" |
> > >    "locality"
> > >    "subsubregion"
> > >    "subregion"
> > >    "region"
> > >    "country-name"
>
> This _could_ work, but it seems a bit weirder than "subsublocality".
>

This would re-define locality, leading to cross-version incompatibilities.


>
>
> > > Or alternatively:
> > >
> > >    "address-line1" |
> > >    "address-line2" |- "street-address"
> > >    "address-line3" |
> > >    "region-level5"
> > >    "region-level4"
> > >    "region-level3" / "locality"
> > >    "region-level2" / "region"
> > >    "region-level1" / "country-name"
>
> This has the advantage of not leaving "country-name" dangling.
>

Yes, but country-name is special: (a) it always comes at the end, (b) it
always exists, (c) calling it "country-name" always makes sense, and (d) it
controls the format of everything else. So I think it's desirable to make
it separate from the sub-country region tokens.


>
>
> > >    "address-line1" |
> > >    "address-line2" |- "street-address"
> > >    "address-line3" |
> > >    "address-level4"
> > >    "address-level3"
> > >    "address-level2" / "locality"
> > >    "address-level1" / "region"
> > >    "country-name"
>
> This could work. It has the synonym issue (having multiple fields that
> mean the same thing is often the source of confusion).
>
>
> > Again, you really can't just put a stack of input fields and have it
> > make sense anywhere. If you are presenting a UI to enter addresses,
> > there's no way you can escape actually knowing how addresses are
> > formatted around the world. (Well, there's requestAutocomplete.)
>
> You still need to know how to render them when printing the label, even
> with requestAutocomplete(). It really does seem like we should either
> document this order, or point to documentation on the topic. Are there Web
> pages out there that provide sufficient information to do this?
>

No, you don't need to know. You use the (not yet spec'd)
"display-address"/"address-blob"/"complete-address" token that was
mentioned up-thread.


>
>
> > I'm not married to the address-levelN name. [something-that-makes-
> > sense]N is fine.
>
> The reason I'm being a bit reluctant to embrace address-level* is that
> it's so close to address-line*.
>

OK. To tell the truth I think address-line1 should probably be
street-address-line1. Would that help clear up the confusion?


>
>
> > The reason we went with proposing address-levelN is because
> > region-levelN implies that all political regions are captured, when they
> > aren't. There's no field for US county because county is never part of
> > an address. So it's only for regions that actually make it onto an
> > envelope.
>
> I don't think the implication is that strong. In fact I'd argue it's the
> other way around -- the implication is that this is for addresses, not
> generic regions.
>

You think region-levelN more strongly implies "only regions relevant to
addresses" than address-levelN does?

Anyway, address-region-levelN, or something, is fine with me.


>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>