Re: [whatwg] Supporting more address levels in autocomplete

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

Received on Saturday, 22 February 2014 00:46:00 UTC