[whatwg] Supporting more address levels in autocomplete

[Evan Stade]

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

> On Tue, 4 Mar 2014, Evan Stade wrote:
> > >
> > > 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?
>
> I don't know. Cargo-cult? Given how poor a job many sites do of this, it's
> not clear to me that it's for helping with customer service. In fact,
> several times the validating has caused me to have to talk to customer
> service to get around their bogus validation.
>
>
> > 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".
>
> Why do we want street addresses in visual order but region components in
> logical order? Is it because in some address schemes the logical
> components end up on the same line with punctuation?
>
>
> > > 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
>
> Fair enough.
>
>
> > > > >    "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).
> > >
> > > > > 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.
>
> Can you elaborate on why this would be worse than the version with
> synonyms?
>

Because these words don't really mean anything. From our initial proposal:

"""
Compared to the alternative of adding another one-off such as
“dependent-locality” or “sub-locality”, we feel this is a more
descriptive and general way to tackle additional administrative levels
without making false implications about the semantics of the value
that is returned.
"""


>
>
> > > > >    "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.
>
> How so? Are people already depending on Chinese addresses' levels 1, 2,
> and 3 being mapped to region, locality, and nothing respectively?
>
> The model with subsubregion does more closely match the specs' current
> descriptions of 'locality'.
>

I would argue that nothing in China reliably matches the spec's current
definition of "locality". That is, in one address, the description for
"locality" matches address-level1, in others, address-level2, etc.

In the US case, I think you're proposing that state would be "region" and
city would be "locality". Then I think it's quite likely that a developer
assumes the intermediate levels like "subregion" would map to county, which
they don't because county is an administrative region irrelevant to
addresses. So I would like to keep region and locality right next to each
other in all cases. But again, since these names don't really make sense
everywhere, just using indexing is the least confusing IMO.


>
>
> > 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.
>
> Fair enough.
>
>
> > > 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.
>
> Why are we ok with getting a multiline text field from the user in this
> case but not without requestAutocomplete()?
>

requestAutocomplete would indeed respect this token just as it respects
other autocomplete tokens. You could use the multiline text field with
requestAutocomplete if that's how you desired to receive the address data
(and you could use it in addition to the tokenized format). This would not
affect the UI of requestAutocomplete though (at least not in Chrome's case).


>
> (I've filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=24935 to track
> the multiline address field.)
>
>
> > > > 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?
>
> Isn't it too late to change the names of the already established ones?
>

address-line1 could be left around for a while (or eternity) for
backwards-compat, while being removed from the spec, no? We're not
replacing it with something new. But I'm fuzzy on the best practices here.


>
>
> > > > 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?
>
> Just the way that this is all about addresses is what I think implies that
> the fields are about addresses.
>

Well, there are other location APIs (like the Google Geocoding API) which
are not about addresses, so they include things that don't go on envelopes.
This almost-analogous API could cause confusion.

Also, not all of autocomplete is related to addresses, e.g. date of birth,
gender, etc. AFAIU, autocomplete is just about data that the user has to
fill in frequently. So I imagine it's not always perfectly clear to a new
developer that this is specifically addresses, as opposed to generic
geolocation. Maybe they mistakenly try to use it to get the user's
geolocation in political terms, rather than coordinates?


>
>
> > Anyway, address-region-levelN, or something, is fine with me.
>
> I think the arguments you've presented so far suggest "address-levelN" for
> N=1..4, with 4=region and 3=locality, is probably the simplest thing to
> do. I was hoping there might be other people with opinions, to give us
> different perspectives on this, but it seems nobody else cares. :-(
>

Again, that's backwards from what we're proposing. Why is that better than
1=region, 2=locality, except to a US-centric viewpoint? This would lead to
a weird situation where (a) you couldn't expand past 4 levels without
changing the meaning of previous levels and (b) a country such as the US
would have address-level4 and address-level3 but no address-level2 or
address-level1.


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