Re: [whatwg] Supporting more address levels in autocomplete

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?


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


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

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


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


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

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

Received on Tuesday, 4 March 2014 23:42:52 UTC