[whatwg] Supporting more address levels in autocomplete

[Evan Stade]

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

> On Tue, 4 Mar 2014, Evan Stade wrote:
> > On Tue, Mar 4, 2014 at 3:41 PM, Ian Hickson <ian at hixie.ch> wrote:
> > > > > > >
> > > > > > >    "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.
> > """
>
> I don't understand how "sublocality" makes any more implications, or has
> any less descriptive value, than "address-level3". Can you elaborate on
> this? They all seem quite neutral (basically empty of meaning) to me.
>

"dependent-locality" and "locality" have a fairly precise meaning in the
UK. Also in a natural-language conversation, if you ask me what "region" of
the country I live in, I'd say "New England", "the Midwest", or some such;
certainly not the state where I reside. The descriptions for these tokens
are currently pretty specific, for example they say a city would be a
locality. But this is not true for Beijing or some other cities. To fix the
descriptions, we'd have to change them to something like "region: the
highest level administrative region below country in the address" and
"locality: the second-highest level administrative region below country in
the address", "sub-locality: the third-highest level administrative region
[...]". At this point, one wonders why the tokens aren't just [something]1,
[something]2, etc.



>
>
> > > > > > >    "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.
>
> Right.
>
>
> > 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.
>
> I don't understand why you think authors will think they need to include
> "subregion", but won't think they need to include "address-level3".
>

I think they'll assume subregion returns something for the US if it's
sandwiched between "region" and "locality", because county is in between
state and city. But in reality, subregion will return nothing.


>
>
> > > > > 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).
>
> That doesn't really answer the question. Why would we bother with all
> these fields if we could just use a <textarea> for the whole address? How
> does requestAutocomplete() change things?
>

Some authors will want it tokenized, some will want it all together. I
anticipate that many sites will want both, because the "display-address"
version would be useful for re-display on the confirmation page, as well as
printing onto a package or envelope, etc., whereas the tokenized version
would probably be necessary for piping data into a backend such as a
payments or shipping provider.


>
>
> > > > > > 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.
>
> Having synonyms is really bad. It leads to huge amounts of confusion. This
> is why I'm trying to avoid having synonyms for the address-level* stuff.
> We should definitely not add some just to introduce a slightly better name.
>

My suggestion is to change the address-line1 to street-address-line1, not
to have synonyms. Chrome would then support address-line1 for a limited
period of time, but outside the spec. Since no other browser have yet
implemented autocomplete at all AFAIK, I don't think we're too entrenched
to make changes. But I'll defer to your judgment here.

If you are avidly anti-synonym for the address-level* stuff, and don't want
to change "region" and "locality", then I guess the next best naming scheme
in my mind would be "region", "locality", "locality2", "locality3". But we
also need to update the descriptions as mentioned above.


>
>
> > > > > > 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?
>
> The other fields in the same gorup include things like "street-address"
> and "postal-code". Things like "bday" and "sex" are in a different group.
>
> But sure, I'll grant you that authors might get confused.
>
>
> > > 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.
>
> Sorry, I got the numbers wrong by mistake. I really do think this
> numbering scheme is confusing...
>

K, didn't mean to harp on this point, just wanted to be clear.


>
>
> > 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.
>
> Well, at least as far as (a) goes, we have no way to know where
> governments are going to introduce new levels. Who's to say that the US
> won't introduce something between states and towns? This problem exists
> whatever we do. Maybe the US and the EU will merge and there'll be a new
> field between "country-name" and "region". Who knows.
>

One can dream...

You're right that changing political circumstances might put us in an
awkward situation no matter what we do. But it seems to me the most likely
scenario is that a government would add more administrative levels at the
most granular level.


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