[whatwg] Supporting more address levels in autocomplete

[Ian Hickson]

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.


> > > > > >    "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".


> > > > 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?


> > > > > 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.


> > > > > 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...


> 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.

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