Re: [whatwg] Supporting more address levels in autocomplete

On Fri, 21 Feb 2014, Dan Beam wrote:
>
> While internationalizing Chrome’s implementation of 
> requestAutocomplete(), we found that Chinese, Korean, and Thai addresses 
> commonly ask for [at least] 3 levels of administrative region. For 
> example, in this Chinese address:
> 
>   Humble Administrator’s Garden
>   n°178 Dongbei Street, Gusu, Suzhou
>   215001 Jiangsu
>   China
> 
> the first-level address component is “Jiangsu” (province) as it’s the 
> first level below country, “Suzhou” is a prefecture level city (below 
> province), and “Gusu” is a district of Suzhou.
> 
> To support this address format and arbitrarily many administrative 
> levels, we propose adding new tokens to the autocomplete spec: 
> address-level-n, for arbitrary n.

This would be the first open-ended field name. Do we really want to make 
this open-ended? What happens if a form has n=1..3, and another has 
n=2..4? What if one has n=1, n=2, and n=4, but not n=3? How does a site 
know how many levels to offer?

What should a Chinese user interacting with a US company put in as their 
address, if they want something shipped to China?


> The current HTML spec supports “region” and “locality”. We feel these 
> should remain in the spec, as they are still useful for typical Western 
> addresses. In a typical Western address, address-level-1 would align 
> with “region” and address-level-2 would align with “locality”.

So they would be synonyms? Or separate fields?

Note that in the case of US addresses, in particular, the "region" field 
is often exposed as a <select> drop-down, not a free-form field. It's 
important that we be consistent as to which field maps to which list of 
names, in cases like this. (I don't know how common this is outside the 
US; I don't recall seeing it in European contexts.)


> 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 agree that at this point, it's better to use numbers than more specific 
names.

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