[whatwg] Supporting more address levels in autocomplete
kevinmarks at gmail.com
Fri Feb 21 16:45:34 PST 2014
Those names come from vcard - if adding a new one, consider how to model it
in vcard too. Note that UK addresses can have this too - eg 3 high street,
Kenton, Harrow, Middlesex, UK
Would putting the 2 degrees of locality as comma separated in that field
make more sense?
Given that this schema is the most widespread addressbook format, I'm sure
someone has a dataset to discover usage (Google? Apple? Microsoft?)
On 21 Feb 2014 16:30, "Ian Hickson" <ian at hixie.ch> wrote:
> 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
> Ian Hickson U+1047E )\._.,--....,'``. fL
> http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
> Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg