This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 24935 - autocomplete: Add an autofill field for the full formatted address
Summary: autocomplete: Add an autofill field for the full formatted address
Status: RESOLVED WONTFIX
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other All
: P4 enhancement
Target Milestone: Needs Impl Interest
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL:
Whiteboard:
Keywords:
Depends on: 22701
Blocks:
  Show dependency treegraph
 
Reported: 2014-03-04 23:17 UTC by Ian 'Hixie' Hickson
Modified: 2019-03-29 20:44 UTC (History)
6 users (show)

See Also:


Attachments

Description Ian 'Hixie' Hickson 2014-03-04 23:17:34 UTC
If we get requestAutocomplete(), it would be useful if we could simultaneously get the country-specific formatted address as a single field.
Comment 1 Evan Stade 2014-03-10 20:51:46 UTC
I propose the token be "display-address". "complete-address" is also OK.
Comment 2 Evan Stade 2014-04-29 23:10:10 UTC
ping. Perhaps simply "address"?
Comment 3 Ian 'Hixie' Hickson 2014-05-06 06:04:37 UTC
Matt, what do you think? (Note that this requires requestAutocomplete() implementations to know how to generate addresses for various locales.)
Comment 4 Matthew Noorenberghe 2014-05-06 06:32:44 UTC
Note that Brian Nicholson is working on requestAutocomplete so he would have a better answer.

Is the format requested in comment 0 that intended for a mailing address? I would think that websites would be in a better position to know how to format mailing labels for the countries they allow shipping to as presumably they're currently formatting them themselves now.

I guess I'd like to hear more about what this is trying to solve as it seems like a maintenance burden to know about the format of addresses in every locale unless there is an open-source project that already maintains this.
Comment 5 Brian Nicholson 2014-05-06 19:39:03 UTC
I agree with Matt -- this sounds like a lot of work to build/maintain an address formatter for every possible locale. Are there existing or proposed specifications outlining these mappings that we could use here?
Comment 6 Evan Stade 2014-05-07 00:16:49 UTC
Absolving individual websites of the need "to know about the format of addresses in every locale" is exactly the problem we're trying to solve :)

Here is one OSS library that does this[1]. Here's a thread with more context[2].

Most importantly, whether or not this type is in the spec, a good implementation of requestAutocomplete has to be locale-aware if it's going to allow users from different countries to enter address information.

[1] https://code.google.com/p/libaddressinput/
[2] http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Feb/0132.html
Comment 7 Matthew Noorenberghe 2014-05-07 05:50:01 UTC
(In reply to Evan Stade from comment #6)
> Absolving individual websites of the need "to know about the format of
> addresses in every locale" is exactly the problem we're trying to solve :)

OK, but unless the output is standardized and consistent between UAs, I'm not sure websites will rely on it. Also, this is a fine goal for new websites but existing shipping websites already would have to know how to format addresses.

> Here is one OSS library that does this[1]. Here's a thread with more
> context[2].

I see that the library is OSS but I can't find any license about the data from the web service. Do you have pointers for that?

> Most importantly, whether or not this type is in the spec, a good
> implementation of requestAutocomplete has to be locale-aware if it's going
> to allow users from different countries to enter address information.

Sure, but knowing which fields to show in UI (booleans) is more straightforward than knowing the postal address formatting (ordering of the fields and delimiters) for each country.
Comment 8 Evan Stade 2014-05-08 00:55:45 UTC
> OK, but unless the output is standardized and consistent between UAs, I'm not 
> sure websites will rely on it. Also, this is a fine goal for new websites but 
> existing shipping websites already would have to know how to format addresses.

As long as it's a blob that makes sense (i.e. you could print it on an envelope or display it on a confirmation page), I think that's good enough.

> I see that the library is OSS but I can't find any license about the data from 
> the web service. Do you have pointers for that?

Sorry, I don't. I can ask around. Regardless, I'm not sure whether the answer to this question should have a bearing on what belongs in HTML.

> Sure, but knowing which fields to show in UI (booleans) is more straightforward 
> than knowing the postal address formatting (ordering of the fields and 
> delimiters) for each country.

You need to know both for address input. An address input form should use the same format that's printed on an envelope. For example, Japan's addresses are more or less opposite of Western style (i.e. large to small instead of small to large). So if you don't get the order right during input, that's a poor user experience. Many (most) existing sites get this wrong, so the distinction made between existing sites/new sites is probably not the right one to make.
Comment 9 Matthew Noorenberghe 2014-05-08 04:39:35 UTC
(In reply to Evan Stade from comment #8)
> > I see that the library is OSS but I can't find any license about the data from 
> > the web service. Do you have pointers for that?
> 
> Sorry, I don't. I can ask around. Regardless, I'm not sure whether the
> answer to this question should have a bearing on what belongs in HTML.

Well, in order to go in HTML my understanding is that two[1] browsers should intend to implement it. If the data isn't available in a spec or somewhere else without manual compilation it's less likely to get implemented. Of course the onus is on us to look to for such databases but it's not a priority at the moment given that we haven't even landed basic rAc. 

> > Sure, but knowing which fields to show in UI (booleans) is more straightforward 
> > than knowing the postal address formatting (ordering of the fields and 
> > delimiters) for each country.
> 
> You need to know both for address input. An address input form should use
> the same format that's printed on an envelope.

Well, I've never seen input fields laid out like that in practice with proper delimiters but I understand the point you're trying to make about field order.

I don't think a new @autocomplete field of this type is something we will initially implement given that we still have a lot to do to implement a more basic version of rAc.

[1] "When there are two or more mature implementations, it may be time to extend the feature to address the nice to have use cases…" – http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F
Comment 10 Evan Stade 2014-05-09 18:23:41 UTC
(In reply to Matthew Noorenberghe from comment #9)
> (In reply to Evan Stade from comment #8)
> > > I see that the library is OSS but I can't find any license about the data from 
> > > the web service. Do you have pointers for that?

The license for that data is the same as the code. The data is actually in the repo here[1]

> Well, in order to go in HTML my understanding is that two[1] browsers should
> intend to implement it.

Ian's opinion has more weight than mine, but it doesn't seem useful to freeze the spec until more than one vendor has implemented it in its current form. If we can agree that a type is useful, why not add it? A site never has a guarantee that a type is supported or will get filled with useful data even on browsers that do support it.

> If the data isn't available in a spec or somewhere
> else without manual compilation it's less likely to get implemented. Of
> course the onus is on us to look to for such databases but it's not a
> priority at the moment given that we haven't even landed basic rAc. 

This type is relevant even for normal autocomplete, not just rAc.

> 
> > > Sure, but knowing which fields to show in UI (booleans) is more straightforward 
> > > than knowing the postal address formatting (ordering of the fields and 
> > > delimiters) for each country.
> > 
> > You need to know both for address input. An address input form should use
> > the same format that's printed on an envelope.
> 
> Well, I've never seen input fields laid out like that in practice with
> proper delimiters but I understand the point you're trying to make about
> field order.

sorry, by both I meant "order and whether to show" not "order and delimiters".

> 
> I don't think a new @autocomplete field of this type is something we will
> initially implement given that we still have a lot to do to implement a more
> basic version of rAc.

That's fine, it's also not something that Chrome implemented in its initial release of requestAutocomplete, but it's something we have the ability and desire to support now.


[1] https://libaddressinput.googlecode.com/svn/trunk/testdata/countryinfo.txt
Comment 11 Ian 'Hixie' Hickson 2014-05-09 23:21:51 UTC
(In reply to Evan Stade from comment #10)
> > Well, in order to go in HTML my understanding is that two[1] browsers should
> > intend to implement it.
> 
> Ian's opinion has more weight than mine, but it doesn't seem useful to
> freeze the spec until more than one vendor has implemented it in its current
> form. If we can agree that a type is useful, why not add it?

What matters is implementation intent. It might be something that two browsers intend to implement sometime next decade, that would be fine and could go in. But if it's something where only one browser wants it at all, that would be a bad sign.


> A site never has a guarantee that a type is supported or will get filled
> with useful data even on browsers that do support it.

That's an interesting point. If the goal is to make it so that sites never have to worry about how to format addresses, aren't we saying that _all_ user agents are going to _have_ to implement this and autofill whenever a user is filling in a form? That seems like something that is unlikely to happen...
Comment 12 Evan Stade 2014-05-10 00:14:56 UTC
> That's an interesting point. If the goal is to make it so that sites never have 
> to worry about how to format addresses, aren't we saying that _all_ user agents 
> are going to _have_ to implement this and autofill whenever a user is filling 
> in a form? That seems like something that is unlikely to happen...

It can be a case of graceful degradation. Let's consider the confirmation page case. After running rAc and getting back a billing address, I want to show the user the info they've entered and allow them to confirm the transaction. I can ask the browser how the address is supposed to be formatted, but still fall back to just mashing the fields together any which-way. In the "print a shipping label" case, I might have to restrict shipping to the US for users whose agent doesn't support this type. But it's still better to offer international shipping to some users rather than none.

Anyway, it doesn't seem that unlikely to me that _all_ browsers would be able to implement this type, given that they support rAc, for the reasons given upthread (basically, it's the same problem as having good international address input support, which should be a goal of any rAc implementation).
Comment 13 Evan Stade 2014-05-15 01:02:52 UTC
So, where do we stand on this issue? Does Mozilla think this type makes sense? Is implementation realistic in light of the library that was linked earlier?
Comment 14 Brian Nicholson 2014-05-15 22:01:58 UTC
(In reply to Evan Stade from comment #12)
> It can be a case of graceful degradation. Let's consider the confirmation
> page case. After running rAc and getting back a billing address, I want to
> show the user the info they've entered and allow them to confirm the
> transaction. I can ask the browser how the address is supposed to be
> formatted, but still fall back to just mashing the fields together any
> which-way. In the "print a shipping label" case, I might have to restrict
> shipping to the US for users whose agent doesn't support this type. But it's
> still better to offer international shipping to some users rather than none.

Are there really businesses that would avoid international shipping simply because of the customer's browser? This seems pretty far-fetched. They're trying to make money, so if they've gone through the trouble to put the infrastructure in place to ship internationally, relying on chance to fulfill orders during checkout seems silly.

> Anyway, it doesn't seem that unlikely to me that _all_ browsers would be
> able to implement this type, given that they support rAc

Perhaps, but I think the bigger issue is whether they will support rAc to begin with. Should we really expect every browser on every platform to support rAc? The answer is almost certainly no, which means web devs need to have some kind of fallback.

If rAc ever becomes ubiquitous, this could be a useful feature. But seeing how its usefulness relies on adoption of other browsers, I don't think we'll want to implement this in the current climate -- especially for a v1 of rAc.
Comment 15 Evan Stade 2014-05-19 20:01:52 UTC
(In reply to Brian Nicholson from comment #14)
> (In reply to Evan Stade from comment #12)
> > It can be a case of graceful degradation. Let's consider the confirmation
> > page case. After running rAc and getting back a billing address, I want to
> > show the user the info they've entered and allow them to confirm the
> > transaction. I can ask the browser how the address is supposed to be
> > formatted, but still fall back to just mashing the fields together any
> > which-way. In the "print a shipping label" case, I might have to restrict
> > shipping to the US for users whose agent doesn't support this type. But it's
> > still better to offer international shipping to some users rather than none.
> 
> Are there really businesses that would avoid international shipping simply
> because of the customer's browser? This seems pretty far-fetched. They're
> trying to make money, so if they've gone through the trouble to put the
> infrastructure in place to ship internationally, relying on chance to
> fulfill orders during checkout seems silly.

It does seem plausible to me that a lot of sites wouldn't want to put in the effort to support the long tail of countries out there.

Using this for shipping labels is supporting a corner case, because most of the time they're probably formatted by your shipper (FedEx, etc.). But that's only *most* of the time. I could imagine a long tail site selling something that could fit in an envelope. Note that eBay/PayPal provide this feature: they tell me the exact, formatted address of where to ship something once I've sold it.

Using this for the order confirmation step is likely to be more common.

> 
> > Anyway, it doesn't seem that unlikely to me that _all_ browsers would be
> > able to implement this type, given that they support rAc
> 
> Perhaps, but I think the bigger issue is whether they will support rAc to
> begin with. Should we really expect every browser on every platform to
> support rAc? The answer is almost certainly no, which means web devs need to
> have some kind of fallback.

That fallback could be "don't have checkout at all". There's at least one major site we've found that simply doesn't have guest checkout on the mobile web because of the problems rAc is trying to solve, but could add guest checkout on their mobile site if the browser has rAc.

> 
> If rAc ever becomes ubiquitous, this could be a useful feature. But seeing
> how its usefulness relies on adoption of other browsers, I don't think we'll
> want to implement this in the current climate -- especially for a v1 of rAc.
Comment 16 Domenic Denicola 2019-03-29 20:44:23 UTC
With W3C Bugzilla shutting down, we are marking all feature requests that remain in the tracker as WONTFIX, or at least wontfix-in-this-tracker.

Feel free to re-raise the issue at https://github.com/whatwg/html/issues if you think it is still relevant. Although it seems like at least some of the motivation here is for requestAutocomplete, which is now gone from the spec.