W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2014

Re: [whatwg] Supporting more address levels in autocomplete

From: Charles McCathie Nevile <chaals@yandex-team.ru>
Date: Sat, 01 Mar 2014 10:30:07 +0100
To: "WHAT Working Group Mailing List" <whatwg@whatwg.org>, "Ian Hickson" <ian@hixie.ch>
Message-ID: <op.xb1d0hjqy3oazb@chaals.local>
On Sat, 01 Mar 2014 02:47:06 +0100, Ian Hickson <ian@hixie.ch> wrote:

> On Mon, 24 Feb 2014, Jukka K. Korpela wrote:
>> 2014-02-22 3:03, Ian Hickson wrote:
>> >
>> > (Note that a lot of people in the UK have no idea how to write their
>> > address according to current standards. For example, people often
>> > include the county, give the "real" town rather than the "post town",
>> > put things out of order, indent each line of the address, etc.)
>>
>> The phenomenon is probably not limited to the UK. Few people even know
>> the current standards (national and international).
>
> Well sure, but since we're writing a standard, if our assumption is that
> people don't know standards, we're not going to reach a useful  
> conclusion.

I don't think that is necessarily true. In a lot of the work done on HTML,  
great care has been taken to minimise the likelihood of people getting  
things wrong, precisely because we don't expect them to know even this  
standard as well as we might like.

[...]

> On Mon, 24 Feb 2014, Charles McCathie Nevile wrote:
>>
>> That depends on whether you want to force your customers to think like
>> the Post Office, or whether you prefer to be responsive to your
>> customers. Speaking without data, I suspect that nervousness at not
>> being able to put *what someone thinks* is their address translates
>> fairly readily into a certain amount of failure to proceed with a
>> transaction.
>
> I'd love to see real data on this. I can imagine scenarios that would  
> lead this to go both ways.

I have only anecdotal evidence (including cases where I have not proceeded  
- having been burnt by proceeding in the past), but it all runs one way.  
Before we go looking for people who do international shipping to provide  
such data, can you outline what sort of scenario goes the other way?

I'm assuming you probably don't mean people would be reassured by a form  
that asks for something which doesn't match what they think they know. Do  
you mean that you can imagine people being reassured when what they think  
their address is fits nicely in the form? Or something else I didn't get?

> On Mon, 24 Feb 2014, Dan Brickley wrote:
>>>
>> Who is using the data? Just post offices? Or taxi drivers, pizza
>> delivery bikers, pedestrians?
>
> The latter three are unlikely to really need much more depth at the
> locality level.

Again, I am not sure that is true - although I need to think it through  
more carefully than I have time for right now. Ditto for the rest of the  
discussion, which I think raises some interesting questions.

cheers

> On Mon, 24 Feb 2014, Evan Stade wrote:
>>
>> Regarding UK addresses, libaddressinput[1], which is used by Google for
>> various products, currently accepts two levels of administrative region
>> for GB: city and optional county.
>
> You need two levels, but those aren't it. :-) Counties haven't officially
> been used in UK addresses since the mid 90s.
>
>
>> > 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?
>>
>> I don't know why a web author would do this
>
> Web authors do all kinds of crazy stuff. We have to be ready for it such
> that we never end up forced to introduce weird heuristics.
>
>
>> but n=m doesn't require n=m-1 or n=m+1 to be present. n=2..4 would just
>> mean the site didn't get the n=1 value.
>
> My concern is that authors do something like this:
>
>    <input ... autocomplete="address-line-1">
>    <input ... autocomplete="address-level-2">
>    <input ... autocomplete="address-level-3">
>
> ...and then the user enters their address:
>
>    1600 Amphitheatre Parkway
>    Mountain View
>    CA
>
> ...and then the user goes to another site:
>
>    <input ... autocomplete="address-line-1">
>    <input ... autocomplete="address-line-2">
>    <input ... autocomplete="address-level-1">
>    <input ... autocomplete="address-level-2">
>    <input ... autocomplete="address-level-3">
>
> ...and the browser autofills:
>
>    1600 Amphitheatre Parkway
>    (empty)
>    Mountain View
>    Mountain View
>    CA
>
> ...or some such.
>
>
>> > How does a site know how many levels to offer?
>>
>> It offers as many as it knows what to do with. It probably wouldn't know
>> what to do with n=5, or n=100, and it's highly unlikely a user agent
>> would return a value for those levels anyway, so practically speaking,
>> n=1 to n=3 should be sufficient for now (although n=4 seems possible in
>> the near future). But I don't see the purpose in setting a limit in the
>> spec.
>
> This makes me extremely uncomfortable.
>
> We're saying, "we don't know how to do this, I hope you do". Why would we
> be less able to answer this than Web authors? It's not like Web authors
> are experts in postal addresses.
>
> I think we should pick the number that is actually needed, and be firm
> that that is the number.
>
>
>> > What should a Chinese user interacting with a US company put in as
>> > their address, if they want something shipped to China?
>>
>> They would put in the same address regardless of the nationality of the
>> company, assuming the company is able to properly handle their address.
>
> Shouldn't we want everyone to be able to handle everyone's address?
>
>
>> Which inputs are visible to the user should depend on which country
>> they're entering. This means that if a user changes the country, the
>> inputs shuffle around and hide or show.
>
> Are we really expecting many sites to do this? I've only seen the most
> advanced sites do this.
>
>
>> > So they would be synonyms? Or separate fields?
>>
>> They are pseudo-synonyms.
>
> I don't know what that means.
>
>
>> In the US, "region" aligns with "address-level-1", and either one would
>> return the same value. In the UAE, where there are cities but no higher
>> level administrative region, "locality" aligns with "address-level-1".
>> In China, "address-level-1" is a province a province-level city such as
>> Beijing. Beijing is also "region", confusingly, and a district of the
>> city is a "locality".
>
> If we're going to do this, we need to have a mapping for every locality
> defined in the spec. This seems like a losing proposition.
>
> Why not make them straight synonyms?
>
>
>> So generally speaking, if I ship to both China and the US, I would
>> create a form with "address-level-[1..4]" and if the user starts to
>> enter a US address, only show the first 2 levels. If the user starts to
>> enter a Chinese address, show more levels. If using requestAutocomplete,
>> all the inputs are hidden all the time anyway.
>
> Are we going to have a list in the spec giving how many levels should be
> given for each country?
>
> Note that the "country" field is often near the end of the form. How do
> you know which country the user is entering an address for when all the
> user's entered is three lines of text?
>
> (Most Web developers don't have access to a reverse geocoder that can
> guess the answer from the first line.)
>
>
> On Tue, 25 Feb 2014, Jürg Lehni wrote:
>>
>> I think it is dangerous to make any kind of assumption about valid
>> postal addresses.
>>
>> Here's a great list of all kinds of exceptions to rules that programmers
>> tend to believe to be true:
>>
>> (Don't we love rules?)
>>
>> http://www.mjt.me.uk/posts/falsehoods-programmers-believe-about-addresses/
>
> I didn't see any there that were contradicted by the assumptions in the
> HTML spec; did you have any particular ones in mind?
>


-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
       chaals@yandex-team.ru         Find more at http://yandex.com
Received on Saturday, 1 March 2014 09:30:40 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:17 UTC