- From: Ian Hickson <ian@hixie.ch>
- Date: Mon, 3 Mar 2014 18:28:29 +0000 (UTC)
- To: Evan Stade <estade@chromium.org>
- Cc: WHAT Working Group Mailing List <whatwg@whatwg.org>
- Message-ID: <alpine.DEB.2.00.1403031804070.32463@ps20323.dreamhostps.com>
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.
> > > > 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.
> > > > 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?
> > > 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.
> 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".
> > 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).
> > 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
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?
> > 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?
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 18:29:36 UTC