Re: [whatwg] Supporting more address levels in autocomplete
On Mon, 3 Mar 2014, Evan Stade wrote: 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). (b) is an easy-to-solve problem: you don't make any of them required, and if the customer entered insufficient fields, they're not getting their package, and will have to be contacted out-of-band. I don't think the additional load that would place on customer service, the number of missing packages, etc., would be considered an easy problem or even an improvement over whatever they currently have in place. I am not convinced it'd be that big a load (users generally know what parts of their addresses are required!). But in any case, if we're talking about mom-and-pop stores with a minimal load of international orders in the first place, it's likely that the customer service load would be pretty minimal. Can you elaborate on (c)? US looks like: Recipient Organization Street address City, State ZIP Japan looks like: 〒 ZIP State City Street address Organization Recipient Ah, interesting. That is indeed a significantly larger difference than I expected. Can you elaborate on these? Where would address-line2 and address-line3 go? Where would country-name go? If the layout difference is that great, we should seriously consider documenting that also. Looking at the suggestions I listed earlier: address-line1 | address-line2 |- street-address address-line3 | address-line5 address-line6 address-line7 / locality address-line8 / region address-line9 / country-name This presumably wouldn't work sanely for Japanese addresses. Or we could do: address-line1 | address-line2 |- street-address address-line3 | subsublocality sublocality locality region country-name This could work. It avoids the synonym problem. address-line1 | address-line2 |- street-address address-line3 | locality subsubregion subregion region country-name This _could_ work, but it seems a bit weirder than subsublocality. Or alternatively: address-line1 | address-line2 |- street-address address-line3 | region-level5 region-level4 region-level3 / locality region-level2 / region region-level1 / country-name This has the advantage of not leaving country-name dangling. address-line1 | address-line2 |- street-address address-line3 | address-level4 address-level3 address-level2 / locality address-level1 / region country-name This could work. It has the synonym issue (having multiple fields that mean the same thing is often the source of confusion). Again, you really can't just put a stack of input fields and have it make sense anywhere. If you are presenting a UI to enter addresses, there's no way you can escape actually knowing how addresses are formatted around the world. (Well, there's requestAutocomplete.) You still need to know how to render them when printing the label, even with requestAutocomplete(). It really does seem like we should either document this order, or point to documentation on the topic. Are there Web pages out there that provide sufficient information to do this? I'm not married to the address-levelN name. [something-that-makes- sense]N is fine. The reason I'm being a bit reluctant to embrace address-level* is that it's so close to address-line*. The reason we went with proposing address-levelN is because region-levelN implies that all political regions are captured, when they aren't. There's no field for US county because county is never part of an address. So it's only for regions that actually make it onto an envelope. I don't think the implication is that strong. In fact I'd argue it's the other way around -- the implication is that this is for addresses, not generic regions. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Supporting more address levels in autocomplete
On Tue, Mar 4, 2014 at 12:18 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 3 Mar 2014, Evan Stade wrote: 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). (b) is an easy-to-solve problem: you don't make any of them required, and if the customer entered insufficient fields, they're not getting their package, and will have to be contacted out-of-band. I don't think the additional load that would place on customer service, the number of missing packages, etc., would be considered an easy problem or even an improvement over whatever they currently have in place. I am not convinced it'd be that big a load (users generally know what parts of their addresses are required!). But in any case, if we're talking about mom-and-pop stores with a minimal load of international orders in the first place, it's likely that the customer service load would be pretty minimal. Then why do so many sites bother to validate data as users input it? Can you elaborate on (c)? US looks like: Recipient Organization Street address City, State ZIP Japan looks like: 〒 ZIP State City Street address Organization Recipient Ah, interesting. That is indeed a significantly larger difference than I expected. Can you elaborate on these? Where would address-line2 and address-line3 go? Where would country-name go? Country name is always at the end. When I put street address above, I meant it in the sense of all the lines of street address. Different countries have a different number of lines, but by definition they're always all next to each other --- the definition of address-line-N is the Nth line of the street address when it's formatted for display. If the layout difference is that great, we should seriously consider documenting that also. I think it's outside the scope of the autocomplete spec, but there are libraries which to do this, such as libaddressinput, which provides a service to get formatting data for various coutnries. For example, the fmt portion of [1] tells you how to format US addresses. Chrome integrates libaddressinput into requestAutocomplete so web authors get this for free, but they could also use the service on their own if they didn't want to rely on requestAutocomplete. [1] https://i18napis.appspot.com/ssl-address/data/US Looking at the suggestions I listed earlier: address-line1 | address-line2 |- street-address address-line3 | address-line5 address-line6 address-line7 / locality address-line8 / region address-line9 / country-name This presumably wouldn't work sanely for Japanese addresses. Or we could do: address-line1 | address-line2 |- street-address address-line3 | subsublocality sublocality locality region country-name This could work. It avoids the synonym problem. Yes, this alternative works, but in my opinion is not preferable. address-line1 | address-line2 |- street-address address-line3 | locality subsubregion subregion region country-name This _could_ work, but it seems a bit weirder than subsublocality. This would re-define locality, leading to cross-version incompatibilities. Or alternatively: address-line1 | address-line2 |- street-address address-line3 | region-level5 region-level4 region-level3 / locality region-level2 / region region-level1 / country-name This has the advantage of not leaving country-name dangling. Yes, but country-name is special: (a) it always comes at the end, (b) it always exists, (c) calling it country-name always makes sense, and (d) it controls the format of everything else. So I think it's desirable to make it separate from the sub-country region tokens. address-line1 | address-line2 |- street-address address-line3 | address-level4 address-level3 address-level2 / locality address-level1 / region country-name This could work. It has the synonym issue (having multiple fields that mean the same thing is often the source of confusion). Again, you really can't just put a stack of input fields and have it make sense anywhere. If you are presenting a UI to enter addresses, there's no way you can escape actually knowing how addresses are formatted around the world. (Well, there's requestAutocomplete.) You still need to know how to render them when printing the label, even with requestAutocomplete(). It really does seem like we should either document this order, or point
Re: [whatwg] Supporting more address levels in autocomplete
On Tue, 4 Mar 2014, Evan Stade wrote: I am not convinced it'd be that big a load (users generally know what parts of their addresses are required!). But in any case, if we're talking about mom-and-pop stores with a minimal load of international orders in the first place, it's likely that the customer service load would be pretty minimal. Then why do so many sites bother to validate data as users input it? I don't know. Cargo-cult? Given how poor a job many sites do of this, it's not clear to me that it's for helping with customer service. In fact, several times the validating has caused me to have to talk to customer service to get around their bogus validation. Country name is always at the end. When I put street address above, I meant it in the sense of all the lines of street address. Different countries have a different number of lines, but by definition they're always all next to each other --- the definition of address-line-N is the Nth line of the street address when it's formatted for display. Why do we want street addresses in visual order but region components in logical order? Is it because in some address schemes the logical components end up on the same line with punctuation? If the layout difference is that great, we should seriously consider documenting that also. I think it's outside the scope of the autocomplete spec, but there are libraries which to do this, such as libaddressinput, which provides a service to get formatting data for various coutnries. For example, the fmt portion of [1] tells you how to format US addresses. Chrome integrates libaddressinput into requestAutocomplete so web authors get this for free, but they could also use the service on their own if they didn't want to rely on requestAutocomplete. [1] https://i18napis.appspot.com/ssl-address/data/US Fair enough. address-line1 | address-line2 |- street-address address-line3 | address-level4 address-level3 address-level2 / locality address-level1 / region country-name This could work. It has the synonym issue (having multiple fields that mean the same thing is often the source of confusion). Or we could do: address-line1 | address-line2 |- street-address address-line3 | subsublocality sublocality locality region country-name This could work. It avoids the synonym problem. Yes, this alternative works, but in my opinion is not preferable. Can you elaborate on why this would be worse than the version with synonyms? address-line1 | address-line2 |- street-address address-line3 | locality subsubregion subregion region country-name This _could_ work, but it seems a bit weirder than subsublocality. This would re-define locality, leading to cross-version incompatibilities. How so? Are people already depending on Chinese addresses' levels 1, 2, and 3 being mapped to region, locality, and nothing respectively? The model with subsubregion does more closely match the specs' current descriptions of 'locality'. Yes, but country-name is special: (a) it always comes at the end, (b) it always exists, (c) calling it country-name always makes sense, and (d) it controls the format of everything else. So I think it's desirable to make it separate from the sub-country region tokens. Fair enough. You still need to know how to render them when printing the label, even with requestAutocomplete(). It really does seem like we should either document this order, or point to documentation on the topic. Are there Web pages out there that provide sufficient information to do this? No, you don't need to know. You use the (not yet spec'd) display-address/address-blob/complete-address token that was mentioned up-thread. Why are we ok with getting a multiline text field from the user in this case but not without requestAutocomplete()? (I've filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=24935 to track the multiline address field.) I'm not married to the address-levelN name. [something-that-makes- sense]N is fine. The reason I'm being a bit reluctant to embrace address-level* is that it's so close to address-line*. OK. To tell the truth I think address-line1 should probably be street-address-line1. Would that help clear up the confusion? Isn't it too late to change the names of the already established ones? The reason we went with proposing address-levelN is because region-levelN implies that all political regions are captured, when they aren't. There's no field for US county because county is never part of an address. So it's only for regions that actually make it onto an envelope. I don't think the implication is that strong. In fact I'd argue it's the other way around -- the implication is that
Re: [whatwg] Supporting more address levels in autocomplete
On Tue, Mar 4, 2014 at 3:41 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 4 Mar 2014, Evan Stade wrote: I am not convinced it'd be that big a load (users generally know what parts of their addresses are required!). But in any case, if we're talking about mom-and-pop stores with a minimal load of international orders in the first place, it's likely that the customer service load would be pretty minimal. Then why do so many sites bother to validate data as users input it? I don't know. Cargo-cult? Given how poor a job many sites do of this, it's not clear to me that it's for helping with customer service. In fact, several times the validating has caused me to have to talk to customer service to get around their bogus validation. Country name is always at the end. When I put street address above, I meant it in the sense of all the lines of street address. Different countries have a different number of lines, but by definition they're always all next to each other --- the definition of address-line-N is the Nth line of the street address when it's formatted for display. Why do we want street addresses in visual order but region components in logical order? Is it because in some address schemes the logical components end up on the same line with punctuation? If the layout difference is that great, we should seriously consider documenting that also. I think it's outside the scope of the autocomplete spec, but there are libraries which to do this, such as libaddressinput, which provides a service to get formatting data for various coutnries. For example, the fmt portion of [1] tells you how to format US addresses. Chrome integrates libaddressinput into requestAutocomplete so web authors get this for free, but they could also use the service on their own if they didn't want to rely on requestAutocomplete. [1] https://i18napis.appspot.com/ssl-address/data/US Fair enough. address-line1 | address-line2 |- street-address address-line3 | address-level4 address-level3 address-level2 / locality address-level1 / region country-name This could work. It has the synonym issue (having multiple fields that mean the same thing is often the source of confusion). Or we could do: address-line1 | address-line2 |- street-address address-line3 | subsublocality sublocality locality region country-name This could work. It avoids the synonym problem. Yes, this alternative works, but in my opinion is not preferable. Can you elaborate on why this would be worse than the version with synonyms? Because these words don't really mean anything. From our initial proposal: Compared to the alternative of adding another one-off such as “dependent-locality” or “sub-locality”, we feel this is a more descriptive and general way to tackle additional administrative levels without making false implications about the semantics of the value that is returned. address-line1 | address-line2 |- street-address address-line3 | locality subsubregion subregion region country-name This _could_ work, but it seems a bit weirder than subsublocality. This would re-define locality, leading to cross-version incompatibilities. How so? Are people already depending on Chinese addresses' levels 1, 2, and 3 being mapped to region, locality, and nothing respectively? The model with subsubregion does more closely match the specs' current descriptions of 'locality'. I would argue that nothing in China reliably matches the spec's current definition of locality. That is, in one address, the description for locality matches address-level1, in others, address-level2, etc. In the US case, I think you're proposing that state would be region and city would be locality. Then I think it's quite likely that a developer assumes the intermediate levels like subregion would map to county, which they don't because county is an administrative region irrelevant to addresses. So I would like to keep region and locality right next to each other in all cases. But again, since these names don't really make sense everywhere, just using indexing is the least confusing IMO. Yes, but country-name is special: (a) it always comes at the end, (b) it always exists, (c) calling it country-name always makes sense, and (d) it controls the format of everything else. So I think it's desirable to make it separate from the sub-country region tokens. Fair enough. You still need to know how to render them when printing the label, even with requestAutocomplete(). It really does seem like we should either document this order, or point to documentation on the topic. Are there Web pages out there that provide sufficient information to do this? No, you
Re: [whatwg] Supporting more address levels in autocomplete
On Tue, 4 Mar 2014, Evan Stade wrote: On Tue, Mar 4, 2014 at 3:41 PM, Ian Hickson i...@hixie.ch wrote: address-line1 | address-line2 |- street-address address-line3 | address-level4 address-level3 address-level2 / locality address-level1 / region country-name This could work. It has the synonym issue (having multiple fields that mean the same thing is often the source of confusion). Or we could do: address-line1 | address-line2 |- street-address address-line3 | subsublocality sublocality locality region country-name This could work. It avoids the synonym problem. Yes, this alternative works, but in my opinion is not preferable. Can you elaborate on why this would be worse than the version with synonyms? Because these words don't really mean anything. From our initial proposal: Compared to the alternative of adding another one-off such as “dependent-locality” or “sub-locality”, we feel this is a more descriptive and general way to tackle additional administrative levels without making false implications about the semantics of the value that is returned. I don't understand how sublocality makes any more implications, or has any less descriptive value, than address-level3. Can you elaborate on this? They all seem quite neutral (basically empty of meaning) to me. address-line1 | address-line2 |- street-address address-line3 | locality subsubregion subregion region country-name This _could_ work, but it seems a bit weirder than subsublocality. This would re-define locality, leading to cross-version incompatibilities. How so? Are people already depending on Chinese addresses' levels 1, 2, and 3 being mapped to region, locality, and nothing respectively? The model with subsubregion does more closely match the specs' current descriptions of 'locality'. I would argue that nothing in China reliably matches the spec's current definition of locality. That is, in one address, the description for locality matches address-level1, in others, address-level2, etc. Right. In the US case, I think you're proposing that state would be region and city would be locality. Then I think it's quite likely that a developer assumes the intermediate levels like subregion would map to county, which they don't because county is an administrative region irrelevant to addresses. So I would like to keep region and locality right next to each other in all cases. But again, since these names don't really make sense everywhere, just using indexing is the least confusing IMO. I don't understand why you think authors will think they need to include subregion, but won't think they need to include address-level3. You still need to know how to render them when printing the label, even with requestAutocomplete(). It really does seem like we should either document this order, or point to documentation on the topic. Are there Web pages out there that provide sufficient information to do this? No, you don't need to know. You use the (not yet spec'd) display-address/address-blob/complete-address token that was mentioned up-thread. Why are we ok with getting a multiline text field from the user in this case but not without requestAutocomplete()? requestAutocomplete would indeed respect this token just as it respects other autocomplete tokens. You could use the multiline text field with requestAutocomplete if that's how you desired to receive the address data (and you could use it in addition to the tokenized format). This would not affect the UI of requestAutocomplete though (at least not in Chrome's case). That doesn't really answer the question. Why would we bother with all these fields if we could just use a textarea for the whole address? How does requestAutocomplete() change things? I'm not married to the address-levelN name. [something-that-makes- sense]N is fine. The reason I'm being a bit reluctant to embrace address-level* is that it's so close to address-line*. OK. To tell the truth I think address-line1 should probably be street-address-line1. Would that help clear up the confusion? Isn't it too late to change the names of the already established ones? address-line1 could be left around for a while (or eternity) for backwards-compat, while being removed from the spec, no? We're not replacing it with something new. But I'm fuzzy on the best practices here. Having synonyms is really bad. It leads to huge amounts of confusion. This is why I'm trying to avoid having synonyms for the address-level* stuff. We should definitely not add some just to introduce a slightly better name.
Re: [whatwg] Supporting more address levels in autocomplete
On Tue, Mar 4, 2014 at 11:41 PM, Ian Hickson i...@hixie.ch wrote: I think the arguments you've presented so far suggest address-levelN for N=1..4, with 4=region and 3=locality, is probably the simplest thing to do. I was hoping there might be other people with opinions, to give us different perspectives on this, but it seems nobody else cares. :-( Since you asked, I think the whole endeavour (of trying to tokenise an address) is pointless and should be abandoned outright. :) Short of my ideal of *only* offering the full address (as used on a label) as an opaque string, I think it would be most reasonable to consider the 'locality' field itself to be a fully-specified opaque string, including whatever information is necessary to completely identify the location from the region level (such as the prefecture and district), rather than a single level. Failing all that, I would at least prefer for the fields to have names instead of abstract numbering, because people are likely to be confused about the order, no matter which end is the 'widest'. It also seems more intuitive, to me, for the 'locality', as, after all, 'local', to be the most specific level.
Re: [whatwg] Supporting more address levels in autocomplete
On Tue, Mar 4, 2014 at 4:39 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 4 Mar 2014, Evan Stade wrote: On Tue, Mar 4, 2014 at 3:41 PM, Ian Hickson i...@hixie.ch wrote: address-line1 | address-line2 |- street-address address-line3 | address-level4 address-level3 address-level2 / locality address-level1 / region country-name This could work. It has the synonym issue (having multiple fields that mean the same thing is often the source of confusion). Or we could do: address-line1 | address-line2 |- street-address address-line3 | subsublocality sublocality locality region country-name This could work. It avoids the synonym problem. Yes, this alternative works, but in my opinion is not preferable. Can you elaborate on why this would be worse than the version with synonyms? Because these words don't really mean anything. From our initial proposal: Compared to the alternative of adding another one-off such as “dependent-locality” or “sub-locality”, we feel this is a more descriptive and general way to tackle additional administrative levels without making false implications about the semantics of the value that is returned. I don't understand how sublocality makes any more implications, or has any less descriptive value, than address-level3. Can you elaborate on this? They all seem quite neutral (basically empty of meaning) to me. dependent-locality and locality have a fairly precise meaning in the UK. Also in a natural-language conversation, if you ask me what region of the country I live in, I'd say New England, the Midwest, or some such; certainly not the state where I reside. The descriptions for these tokens are currently pretty specific, for example they say a city would be a locality. But this is not true for Beijing or some other cities. To fix the descriptions, we'd have to change them to something like region: the highest level administrative region below country in the address and locality: the second-highest level administrative region below country in the address, sub-locality: the third-highest level administrative region [...]. At this point, one wonders why the tokens aren't just [something]1, [something]2, etc. address-line1 | address-line2 |- street-address address-line3 | locality subsubregion subregion region country-name This _could_ work, but it seems a bit weirder than subsublocality. This would re-define locality, leading to cross-version incompatibilities. How so? Are people already depending on Chinese addresses' levels 1, 2, and 3 being mapped to region, locality, and nothing respectively? The model with subsubregion does more closely match the specs' current descriptions of 'locality'. I would argue that nothing in China reliably matches the spec's current definition of locality. That is, in one address, the description for locality matches address-level1, in others, address-level2, etc. Right. In the US case, I think you're proposing that state would be region and city would be locality. Then I think it's quite likely that a developer assumes the intermediate levels like subregion would map to county, which they don't because county is an administrative region irrelevant to addresses. So I would like to keep region and locality right next to each other in all cases. But again, since these names don't really make sense everywhere, just using indexing is the least confusing IMO. I don't understand why you think authors will think they need to include subregion, but won't think they need to include address-level3. I think they'll assume subregion returns something for the US if it's sandwiched between region and locality, because county is in between state and city. But in reality, subregion will return nothing. You still need to know how to render them when printing the label, even with requestAutocomplete(). It really does seem like we should either document this order, or point to documentation on the topic. Are there Web pages out there that provide sufficient information to do this? No, you don't need to know. You use the (not yet spec'd) display-address/address-blob/complete-address token that was mentioned up-thread. Why are we ok with getting a multiline text field from the user in this case but not without requestAutocomplete()? requestAutocomplete would indeed respect this token just as it respects other autocomplete tokens. You could use the multiline text field with requestAutocomplete if that's how you desired to receive the address data (and you could use it in addition to the tokenized
Re: [whatwg] Supporting more address levels in autocomplete
On Tue, Mar 4, 2014 at 4:52 PM, Qebui Nehebkau qebui.nehebkau+wha...@gmail.com wrote: On Tue, Mar 4, 2014 at 11:41 PM, Ian Hickson i...@hixie.ch wrote: I think the arguments you've presented so far suggest address-levelN for N=1..4, with 4=region and 3=locality, is probably the simplest thing to do. I was hoping there might be other people with opinions, to give us different perspectives on this, but it seems nobody else cares. :-( Since you asked, I think the whole endeavour (of trying to tokenise an address) is pointless and should be abandoned outright. :) Short of my ideal of *only* offering the full address (as used on a label) as an opaque string, The majority of forms ask for tokenized data; my impression is this is necessary given their backends (be it columns in a user info database, a payment provider that requires tokenized address, etc.) So I don't think it's practical to impose address blob only on the web.
Re: [whatwg] Supporting more address levels in autocomplete
On Wed, Mar 5, 2014 at 2:54 AM, Evan Stade est...@chromium.org wrote: The majority of forms ask for tokenized data; my impression is this is necessary given their backends (be it columns in a user info database, a payment provider that requires tokenized address, etc.) So I don't think it's practical to impose address blob only on the web. Right, impose, certainly not. But, perhaps, (one hopes,) encourage? Or at least refuse to explicitly support anything else. Does autocomplete *need* to support people who are already doing it wrong? But I'm probably just being too utopian; it happens.
Re: [whatwg] Supporting more address levels in autocomplete
On Fri, 28 Feb 2014, Evan Stade wrote [slightly edited for correctness]: On Fri, Feb 28, 2014 at 5:47 PM, Ian Hickson i...@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
Re: [whatwg] Supporting more address levels in autocomplete
On Mon, Mar 3, 2014 at 10:28 AM, Ian Hickson i...@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 i...@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
Re: [whatwg] Supporting more address levels in autocomplete
On Mon, 3 Mar 2014, Evan Stade wrote: I'm still confused. The site author has entered bad markup. Is your concern that site authors will be unable to write good markup? Some will write good markup, I'm sure. Our job as language designers is to maximise the number of authors doing a good job, and minimise the number of authors who make unintentional mistakes. There's no point us allowing address-level881. It will never be useful. Is there a point in disallowing it? Yeah. It simplifies the language, means there's less to test so it simplifies testing, it simplifies authoring, it reduces tutorial complexity, it makes answering questions like how many should I include easy to answer, and so on. Ultimately it doesn't matter too much, but I would think it's a goal to avoid spec churn. Adding features isn't such a big deal, especially when they're in response to changing political conditions. If we're going to set some limit, let's say 4. Ok. 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. If you take the fields from the spec today and those proposed in this thread, and concatenate them one-to-a-line in the following order: organization address-line1 address-line2 address-line3 address-level4 address-level3 address-level2 address-level1 country-name postal-code ...the mail is going to get where you want it to get, right? So for the mom-and-pop store, this seems like it would be sufficient. Even if they render it as: organization address-line1 address-line2 address-line3 address-level4, address-level3 postal-code address-level2 address-level1 country-name ...so that it's optimised for the US, it would still work everywhere, you'd just have some slightly annoyed postal staff in some countries. So I don't think it's right to say that address-level* doesn't help you in the mom-and-pop store case. It does. 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). (b) is an easy-to-solve problem: you don't make any of them required, and if the customer entered insufficient fields, they're not getting their package, and will have to be contacted out-of-band. Can you elaborate on (c)? If this is something that's required to make user of these autofill fields, then we should explain to authors what they need to do. 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. Then why would UAE be missing address-level1? I'm confused. The reason I say this is backwards is that it is the reverse of the address-line* fields. This could be confusing. One question is whether the current locality, which is defined as City, town, village, post town, or other locality within which the relevant street address is found, should map to 4 or 2. If it maps to 2, we'll probably have to change the way we define this to be more generic. 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
Re: [whatwg] Supporting more address levels in autocomplete
On Mon, Mar 3, 2014 at 2:18 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 3 Mar 2014, Evan Stade wrote: I'm still confused. The site author has entered bad markup. Is your concern that site authors will be unable to write good markup? Some will write good markup, I'm sure. Our job as language designers is to maximise the number of authors doing a good job, and minimise the number of authors who make unintentional mistakes. There's no point us allowing address-level881. It will never be useful. Is there a point in disallowing it? Yeah. It simplifies the language, means there's less to test so it simplifies testing, it simplifies authoring, it reduces tutorial complexity, it makes answering questions like how many should I include easy to answer, and so on. Ultimately it doesn't matter too much, but I would think it's a goal to avoid spec churn. Adding features isn't such a big deal, especially when they're in response to changing political conditions. If we're going to set some limit, let's say 4. Ok. 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. If you take the fields from the spec today and those proposed in this thread, and concatenate them one-to-a-line in the following order: organization address-line1 address-line2 address-line3 address-level4 address-level3 address-level2 address-level1 country-name postal-code ...the mail is going to get where you want it to get, right? So for the mom-and-pop store, this seems like it would be sufficient. Even if they render it as: organization address-line1 address-line2 address-line3 address-level4, address-level3 postal-code address-level2 address-level1 country-name ...so that it's optimised for the US, it would still work everywhere, you'd just have some slightly annoyed postal staff in some countries. Or some automatic mail-sorting machines which reject your mail completely. I think you have more confidence in the post office than I do. But again, this is something to be addressed separately with a display-address token (or whatever you want to call it). So I don't think it's right to say that address-level* doesn't help you in the mom-and-pop store case. It does. In some sense, you could put all the components of the address in a completely random order and if you're lucky, they'll be unambiguous enough for some human to figure it out. I don't think we should recommend people do that though. 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). (b) is an easy-to-solve problem: you don't make any of them required, and if the customer entered insufficient fields, they're not getting their package, and will have to be contacted out-of-band. I don't think the additional load that would place on customer service, the number of missing packages, etc., would be considered an easy problem or even an improvement over whatever they currently have in place. Can you elaborate on (c)? US looks like: Recipient Organization Street address City, State ZIP Japan looks like: 〒 ZIP State City Street address Organization Recipient Using the US format for a Japanese address would be fantastically bad. Users in Japan would probably just enter their address in the way they think of as forwards but your website thinks of as backwards meaning you get the exact problem you pointed out earlier. If this is something that's required to make user of these autofill fields, then we should explain to authors what they need to do. 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.
Re: [whatwg] Supporting more address levels in autocomplete
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. Alex -- Alex Bishop alexbis...@gmail.com
Re: [whatwg] Supporting more address levels in autocomplete
Alex Bishop alexbis...@gmail.com writes: 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. In Germany, forms do have something called „Adresszusatz“ (literally: “address extension”), for everything more specific than name, street, postal code, city. A company campus, for example, may have only one postal address, but mail addressed to a specific division may contain something like “building 3 entrance C”. A person temporarily reachable by mail at someone else's place may have “c/o john doe”. I personally experience problems because of this, as where I live only the apartment number is on the mail box (administration forbids writing one's own name on this) and mail often arrives late because of that. 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? -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Supporting more address levels in autocomplete
On Sat, 01 Mar 2014 02:47:06 +0100, Ian Hickson i...@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
Re: [whatwg] Supporting more address levels in autocomplete
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. 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 On Mon, 24 Feb 2014, Evan Stade wrote: 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). We can definitely add something like this. We already have a simpler version of this for street addresses. 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. 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. 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
Re: [whatwg] Supporting more address levels in autocomplete
On Fri, Feb 28, 2014 at 5:47 PM, Ian Hickson i...@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. 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 On Mon, 24 Feb 2014, Evan Stade wrote: 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). We can definitely add something like this. We already have a simpler version of this for street addresses. 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. 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. 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. So the user is tricked into entering wrong data? (i.e. CA for address-level-3 instead of address-level-1) A web author could just as easily cause the user to enter wrong data to be stored by doing: input type=text autocomplete=address-line-1 placeholder=Zip code How does a site know how many levels to offer? It offers as many as it knows what to do with. It
Re: [whatwg] Supporting more address levels in autocomplete
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/ Jürg On Feb 22, 2014, at 05:05 , 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. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
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/
Re: [whatwg] Supporting more address levels in autocomplete
On Fri, 21 Feb 2014, Dan Beam wrote: While internationalizing Chrome’s implementation of requestAutocomplete(), we found that Chinese, Korean, and Thai addresses commonly ask for [at least] 3 levels of administrative region. For example, in this Chinese address: Humble Administrator’s Garden n°178 Dongbei Street, Gusu, Suzhou 215001 Jiangsu China the first-level address component is “Jiangsu” (province) as it’s the first level below country, “Suzhou” is a prefecture level city (below province), and “Gusu” is a district of Suzhou. To support this address format and arbitrarily many administrative levels, we propose adding new tokens to the autocomplete spec: address-level-n, for arbitrary n. 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? How does a site know how many levels to offer? What should a Chinese user interacting with a US company put in as their address, if they want something shipped to China? The current HTML spec supports “region” and “locality”. We feel these should remain in the spec, as they are still useful for typical Western addresses. In a typical Western address, address-level-1 would align with “region” and address-level-2 would align with “locality”. So they would be synonyms? Or separate fields? Note that in the case of US addresses, in particular, the region field is often exposed as a select drop-down, not a free-form field. It's important that we be consistent as to which field maps to which list of names, in cases like this. (I don't know how common this is outside the US; I don't recall seeing it in European contexts.) Compared to the alternative of adding another one-off such as “dependent-locality” or “sub-locality”, we feel this is a more descriptive and general way to tackle additional administrative levels without making false implications about the semantics of the value that is returned. I agree that at this point, it's better to use numbers than more specific names. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Supporting more address levels in autocomplete
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 Would putting the 2 degrees of locality as comma separated in that field make more sense? Given that this schema is the most widespread addressbook format, I'm sure someone has a dataset to discover usage (Google? Apple? Microsoft?) On 21 Feb 2014 16:30, Ian Hickson i...@hixie.ch wrote: On Fri, 21 Feb 2014, Dan Beam wrote: While internationalizing Chrome’s implementation of requestAutocomplete(), we found that Chinese, Korean, and Thai addresses commonly ask for [at least] 3 levels of administrative region. For example, in this Chinese address: Humble Administrator’s Garden n°178 Dongbei Street, Gusu, Suzhou 215001 Jiangsu China the first-level address component is “Jiangsu” (province) as it’s the first level below country, “Suzhou” is a prefecture level city (below province), and “Gusu” is a district of Suzhou. To support this address format and arbitrarily many administrative levels, we propose adding new tokens to the autocomplete spec: address-level-n, for arbitrary n. 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? How does a site know how many levels to offer? What should a Chinese user interacting with a US company put in as their address, if they want something shipped to China? The current HTML spec supports “region” and “locality”. We feel these should remain in the spec, as they are still useful for typical Western addresses. In a typical Western address, address-level-1 would align with “region” and address-level-2 would align with “locality”. So they would be synonyms? Or separate fields? Note that in the case of US addresses, in particular, the region field is often exposed as a select drop-down, not a free-form field. It's important that we be consistent as to which field maps to which list of names, in cases like this. (I don't know how common this is outside the US; I don't recall seeing it in European contexts.) Compared to the alternative of adding another one-off such as “dependent-locality” or “sub-locality”, we feel this is a more descriptive and general way to tackle additional administrative levels without making false implications about the semantics of the value that is returned. I agree that at this point, it's better to use numbers than more specific names. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Supporting more address levels in autocomplete
On Fri, 21 Feb 2014, Kevin Marks wrote: Would putting the 2 degrees of locality as comma separated in that field make more sense? Given that this schema is the most widespread addressbook format, I'm sure someone has a dataset to discover usage (Google? Apple? Microsoft?) That's a reasonable set of questions. Anyone? 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. (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.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Supporting more address levels in autocomplete
On 21 Feb 2014 17:03, Ian Hickson i...@hixie.ch wrote: On Fri, 21 Feb 2014, Kevin Marks 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 (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.) 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). UK forms tend to ask for postcode and street number these days, and barf when given US addresses
Re: [whatwg] Supporting more address levels in autocomplete
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. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
