Re: [whatwg] Supporting more address levels in autocomplete

On Mon, Mar 3, 2014 at 10:28 AM, Ian Hickson <ian@hixie.ch> wrote:

> On Fri, 28 Feb 2014, Evan Stade wrote [slightly edited for correctness]:
> > On Fri, Feb 28, 2014 at 5:47 PM, Ian Hickson <ian@hixie.ch> wrote
> > [slightly edited for correctness]:
> > >
> > > My concern is that authors do something like this:
> > >
> > >    <input ... autocomplete="address-line1">
> > >    <input ... autocomplete="address-level2">
> > >    <input ... autocomplete="address-level3">
> > >
> > > ...and then the user enters their address:
> > >
> > >    1600 Amphitheatre Parkway
> > >    Mountain View
> > >    CA
> > >
> > > ...and then the user goes to another site:
> > >
> > >    <input ... autocomplete="address-line1">
> > >    <input ... autocomplete="address-line2">
> > >    <input ... autocomplete="address-level1">
> > >    <input ... autocomplete="address-level2">
> > >    <input ... autocomplete="address-level3">
> > >
> > > ...and the browser autofills:
> > >
> > >    1600 Amphitheatre Parkway
> > >    (empty)
> > >    Mountain View
> > >    Mountain View
> > >    CA
> > >
> > > ...or some such.
> >
> > So the user is tricked into entering wrong data?
>
> No, the user enters correct data, and the site uses it fine. The problem
> is just that the site author got the autocomplete="" field names wrong.
>
>
> > (i.e. CA for address-level3 instead of address-level1) A web author
> > could just as easily cause the user to enter wrong data to be stored by
> > doing:
> >
> >   <input type="text" autocomplete="address-line1" placeholder="Zip code">
>
> This is a concern, but far less of one, IMHO, since there's a dedicated
> "postal-code" field.
>

I'm still confused. The site author has entered bad markup. Is your concern
that site authors will be unable to write good markup? Is there a name for
these fields that you think would be less confusing to the authors?


>
>
> > > > > 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.
> >
> > That's not how I would interpret it. We do know how many levels we
> > currently support.
>
> How many? Let's put that number in the spec.


>
> > We don't know how many levels we might support in the future. The number
> > depends on political forces.
>
> Sure. We can always change the spec when we change the implementations.


> There's no point us allowing address-level881. It will never be useful.
>

Is there a point in disallowing it?

Ultimately it doesn't matter too much, but I would think it's a goal to
avoid spec churn. If we're going to set some limit, let's say 4.


>
>
> > > > > 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?
> >
> > I think I've misunderstood your original question because I don't know
> > how my answer indicates someone would not be able to handle someone's
> > address. But to answer the new question, no: if I am only willing to
> > ship to US addresses, why do I need to be able to handle a Chinese
> > address?
>
> Well if for some reason you want to exclude non-US customers, sure. But
> suppose you do want to include all customers, but you're a mom-and-pop
> store who is just going to put what you put in the form onto the envelope,
> and who doesn't know the intricacies of each country's postal standards.
>
> How many fields should you list?
>

In this case, address-level-n doesn't help you. In order to be able to
write an address onto an envelope, you want an address blob, not tokenized
bits. This address blob was proposed further up the thread, and I think
it's a good idea, but distinct from the current topic, which is how to get
tokenized bits for places like China.

Of course, tokenized bits can be used to create an address blob, but it
requires some sophistication to do so.


>
>
> > > > 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.
> >
> > Nope, I wouldn't expect many sites to roll their own solution for this,
> > which is also why most sites are completely broken at accepting
> > international addresses.
>
> This seems like something we should fix.
>

I don't think the autocomplete spec is going to solve the problem of
telling authors how to write their markup, but for the markup they do
write, it will assist the user in filling in data quickly and accurately.

The spec that does address the question of how to easily provide
non-trivial UI is of course requestAutocomplete.


>
>
> > But requestAutocomplete offers a much easier way to support
> > international addresses well: all the UX concerns you're raising are
> > handled by the browser, which is an advanced piece of software.
>
> Well, I agree, but unfortunately requestAutocomplete() remains a
> Chrome-proprietary feature for now, so until other vendors show the
> slightest interest in implementing it, we shouldn't let that impact how we
> design the spec. The autofill fields are intended to be backwards-
> compatible with browsers that ignore them.
>
> Given that not everyone is going to use requestAutocomplete(), and not
> everyone is going to write elaborate per-country support, we're still left
> with the question of "how many levels should people who are ok with
> shipping internationally include".
>

I don't think you can just write a stack of inputs that accepts input for
any country. The country determines:

a) what fields make sense
b) what fields are required
c) the order of fields

You could ignore (a) and settle for a crappy UI that shows all fields that
make sense anywhere in the world, but you'd still be left with solving (b)
and (c).


>
>
> > > 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.
> >
> > Does the spec define localities? I wasn't aware there was any definition
> > for the data values, only data types.
>
> Right now there doesn't need to be a definition, because there's only one
> field. ("locality" is defined as "City, town, village, post town, or other
> locality within which the relevant street address is found".) But if we
> introduce a new kind of address field, we need to define how it maps to
> the existing ones.
>
> My preferred solution would be to just have a direct mapping -- "locality"
> and "address-level1" are equivalent, and "region" and "address-level2" are
> equivalent, and we allow N more address-level* fields (where N is whatever
> is needed today and thus supported by browsers), and we recommend that
> authors include all of them (the N fields) if they're not doing
> country-specific UIs (either one country, or automatically updating the UI
> like big online stores might).
>

This is backwards. "region" is bigger than "locality". "address-level-n" is
bigger than "address-level-n+1"

Aside from that reversal, I'm willing to give up this point and accept
exact synonyms in the name of moving this discussion forward.


>
>
> > > Why not make them straight synonyms?
> >
> > It seems counter-intuitive to have "address-level2" but not
> > "address-level1" for a country, which would be the case for the UAE (for
> > example) if we went with exact synonyms.
>
> I would recommend having only address-level1 for UAE, and it would map to
> "locality". Basically, "locality" and "region" here would be deprecated
> values.
>
> Alternatively, if "region" is always the last address-level* value, then
> we could just do the mapping backwards:
>
>    address-line1
>    address-line2
>    address-line3
>    address-levelN
>    ...
>    address-level3
>    address-level2 = locality
>    address-level1 = region
>

This isn't backwards, this is what we're proposing.


>
> But maybe we can do better, and just have dedicated names. What countries
> need more than two, today? How many do they each need? What are they? If
> we had hard data here it might be easier to design a better solution; do
> you happen to have that data?
>

At least Korea, China, and Thailand need the third level. I think China
will need a 4th soon. Here's a rundown for Chinese administrative levels:
http://en.wikipedia.org/wiki/Administrative_divisions_of_China

The three that make it onto the envelope currently are:
"Provincial level"
"Prefectural level"
"County level"

You can click through on the wikipedia link for explanations of the various
forms these levels take.

I don't think dedicated names are advisable given the wide variety of names
for each address level (even within a single country, much less across all
countries). For example, "region" is already super generic and unhelpful.


>
>
> > > Are we going to have a list in the spec giving how many levels should
> > > be given for each country?
> >
> > No. That is up to the site's ability to handle the data. For example, if
> > I'm soliciting *just* US addresses, I wouldn't know what to do with
> > address-level3, hence I won't ask for it.
>
> Ok. What do you do if you're soliciting addresses from any country?
>

I put all the fields my database or payments backend or w/e can handle. If
there's no column for address-level-4 in my database, I don't put a field
for address-level-4 in my webpage.

Then I hide them all and invoke requestAutocomplete. Or I write complicated
JS to manipulate my markup to show the user what they expect to see based
on which country they're entering info for (hide the fields that don't make
sense, mark "required" for the ones that are necessary, etc.)


>
>
> On Sat, 1 Mar 2014, Charles McCathie Nevile wrote:
> > On Sat, 01 Mar 2014 02:47:06 +0100, Ian Hickson <ian@hixie.ch> wrote:
> > > On Mon, 24 Feb 2014, Jukka K. Korpela wrote:
> > > >
> > > > 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.
>
> Right, that's what we're doing here.
>
>
> > > 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?
>
> Maybe users look at the form, realise their address can be written much
> more easily than they realised, and the perceived reduction in complexity
> leads them to being more open to future e-commerce transactions.
>
> (In any case, nothing being proposed here would affect this one way or the
> other. If you have a concrete proposal to change this, let us know!)
>
>
> On Sun, 2 Mar 2014, Alex Bishop wrote:
> > On 22/02/2014 04:05, Ian Hickson wrote:
> > > The post office will deal with all kinds of stuff, sure. But Web forms
> > > only have to accept the formal address format, which in the UK only
> > > ever has a street, a locality (sometimes), a post town, and a post
> > > code.
> >
> > That’s all Royal Mail has to deal with, sure (with the possible addition
> > of a named building on a street, which almost always seems to merit its
> > own line), but don’t forget that there can be additional lines above
> > that for flat numbers, office departments, buildings on a site, etc. In
> > my experience, it’s not uncommon for business or university hall of
> > residence addresses to have two or three lines before the street part.
>
> Those are all above the address-level* fields that we're talking about
> here. The spec already has a free-form, multiline field for this kind of
> thing: "street-address". It also allows this to be broken down into three
> single-line fields for sites who don't want to allow multiline input here
> for whatever reason: "address-line1", "address-line2", "address-line3".
>
>
> On Sun, 2 Mar 2014, Nils Dagsson Moskopp wrote:
> >
> > Btw, do we have a collection of real world use cases for address forms?
> > One first thing that came to my mind for me is food delivery services,
> > which have to deal with addresses often and in a timely manner:
> >
> > <http://www.lieferheld.de/> has a single input field for each of:
> >   - family name
> >   - company
> >   - street
> >   - house number
> >   - floor
> >   - postal code
> >   - city
> >   - special directions
> >
> > <http://www.lieferando.de> has a single input field for each of:
> >   - given name
> >   - family name
> >   - street
> >   - house number
> >   - company
> >   - floor
> >   - further information
> >
> > <http://pizza.de> has a single input field for each of:
> >   - company
> >   - company division
> >   - given name
> >   - family name
> >   - street
> >   - house number
> >   - postal code
> >   - city
> >   - backyard / floor / etc.
> >
> > Based on my small sample, both “company” and “floor” seem to be
> > candidates for address completion. Also, every one of these forms has an
> > address extension field for further information, with different labels.
> >
> > What would be an argument against generic address extension input fields
> > for free form text that does not fit into any other input field?
>
> Generic fields in general don't work because the fields aren't actually
> generic. If one site uses one generic field for "floor" and the other for
> "house number", and another does the opposite, the autofill feature fails
> in a pretty poor way (hard to notice early, but fatal to the final
> delivery of the pizza or whatever).
>
> But in any case, this is getting somewhat afar from the topic of this
> thread, which is about the locality levels, not the street address levels.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

Received on Monday, 3 March 2014 19:34:07 UTC