Re: [whatwg] Supporting more address levels in autocomplete
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). I think it would be more important to have the option of using less address levels, rather than more. Some fine-grained control for naming different components of an address are undoubtedly useful at times. It would be even more useful to have a common, standard name for just an address. That is, whatever someone wants the sender to put in an envelope. Its internal structure does not matter, as long as it works, and as usual, it is up to the recipient to specify the address in a manner that works. Forms that require the user to split his address to small pieces may have their reasons. But if you just want to have an address to send stuff to, then all you need is a working postal address. A textarea with, say, name=postal, if used on different pages, would then let the user enter his entire address very simply, after just once typing it. Probably postal should be specified so that it relates to a postal address that is complete for delivery except the recipient name. The reason is that the name is so often asked separately Yucca
Re: [whatwg] Supporting more address levels in autocomplete
On Sat, 22 Feb 2014 05:05:06 +0100, Ian Hickson i...@hixie.ch wrote: On Fri, 21 Feb 2014, Kevin Marks wrote: On 21 Feb 2014 17:03, Ian Hickson i...@hixie.ch wrote: 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 That's actually a bogus UK address. I'm not sure exactly which town you meant that to be in, but official UK addresses never have more than two region levels, and usually only one (the post town). The only time they have two is when the post town has two streets with the same name. The real address, where I grew up, was: 2 Melbury Road, Kenton, Harrow, Middlesex, HA3 9RA Today, the address of that building is: 2 Melbury Rd Harrow HA3 9RA Damn humans, not following specs. Actually UK addresses have a huge amount of leeway, as they are routed by postcode in the main (though I did receive a postcard addressed to Kevin, Sidney, Cambridge once). 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 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. Providing specification purity over the concerns of both users and developers trying to use the Web to successfully interact with them seems like a pretty basic mistake to me. cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: [whatwg] Supporting more address levels in autocomplete
On 24 Feb 2014 05:17, Charles McCathie Nevile cha...@yandex-team.ru wrote: On Sat, 22 Feb 2014 05:05:06 +0100, Ian Hickson i...@hixie.ch wrote: On Fri, 21 Feb 2014, Kevin Marks wrote: On 21 Feb 2014 17:03, Ian Hickson i...@hixie.ch wrote: 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 That's actually a bogus UK address. I'm not sure exactly which town you meant that to be in, but official UK addresses never have more than two region levels, and usually only one (the post town). The only time they have two is when the post town has two streets with the same name. The real address, where I grew up, was: 2 Melbury Road, Kenton, Harrow, Middlesex, HA3 9RA Today, the address of that building is: 2 Melbury Rd Harrow HA3 9RA Damn humans, not following specs. Actually UK addresses have a huge amount of leeway, as they are routed by postcode in the main (though I did receive a postcard addressed to Kevin, Sidney, Cambridge once). 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 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. Providing specification purity over the concerns of both users and developers trying to use the Web to successfully interact with them seems like a pretty basic mistake to me. Who is using the data? Just post offices? Or taxi drivers, pizza delivery bikers, pedestrians? Dan cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: [whatwg] Supporting more address levels in autocomplete
(Trying again from alternate email address; apologies if this message shows up twice.) 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. 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, 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. 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. 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. 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. (requestAutocomplete places the onus of understanding all this on the user agent, but there are javascript implementations out there.) So they would be synonyms? Or separate fields? They are pseudo-synonyms. 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. 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. If I am making a site that ships to just the US, I'd probably go with the more intuitive region and locality and ignore address-level-n. Forms that require the user to split his address to small pieces may have their reasons. But if you just want to have an address to send stuff to, then all you need is a working postal address. A textarea with, say, name=postal, if used on different pages, would then let the user enter his entire address very simply, after just once typing it. I agree with this, and plan to propose it separately from the proposal currently under discussion. It might be hard to parse a working address out of a free-form input, but the other direction is doable enough: creating a block of text suitable to printing on an envelope given tokenized values. This tackles the problem of how to format an autocompleted address for a particular country and UI language (i.e. in the user agent has to know how to do it, but the website doesn't). -- Evan Stade [1] https://code.google.com/p/libaddressinput/
