Re: [whatwg] Proposal:Improve internationalization in the autocomplete attribute
On Tue, 30 Jul 2013, Lara Rennie wrote: If they want a separate field, they can trivially just extract out the CEDEX bit by looking for the word CEDEX in the locality, and stripping it out if it's present. I would expect most implementations not to bother (since there doesn't seem to be any reason to -- just pretend the locality has CEDEX in the name, and it all works, no?). When you said you expect most implementations not to bother; this is not my experience at all. Any implementation that wants to find the address on the map would have to strip it out, and anyone who wants to do statistical analysis. Most implementations I've seen don't even offer the field. For example, I went to Amazon UK and tried to ship to a French address, and there was no mention of CEDEX anywhere. CEDEX is usually followed by a number - as per Address Doctor A CEDEX address is built of 5 characters followed by the locality name and the word CEDEX. This code can be followed by another identification number if there are more than one distribution points in one locality. If there is more than one arrondissement in one locality, the CEDEX code is followed by the one of the arrondissement. That just seems to make it even more part of the locality, to me. That is, the locality is either Paris or Paris CEDEX 04 or whatnot. Here's a random doc showing a CEDEX address: http://www.claudereichman.com/articles/Document%20CNAV0001.pdf The text-field is supposed to be filled in with the appropriate number. I agree this is not so intuitive for people who just want to say CEDEX without a number; maybe it should be a tick-box, and then once you've ticked it, you can optionally enter a number. I'm still thinking that this is rare enough that we shouldn't support it with its own dedicated field. In particular, since it's so rare that most people don't implement it, we'd have to come up with a way to split up the information when only one field was available, anyway. This just seems like a world of pain. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal:Improve internationalization in the autocomplete attribute
On Thu, 27 Jun 2013, Lara Rennie wrote: Re the CEDEX: it is a postal-code like thing, but it can't go in the postal-code field, or formatting would be bizarre; as pointed out, it should go after the locality field. However, if it was entered in the locality field, certain systems may complain about validation, anyone interested in aggregating data will start to get a lot of duplicate localities etc. It's also not just France - many ex-French colonies use this too. The Google Address Widget does actually accept CEDEX as a separate field; but you won't see this in most use-cases, because often the widget is used to collect a physical address (and then they disallow it), or it's used to give an address to a credit-card company (who are US based, and don't understand it or want things they don't understand...) Re the physical vs. mailing: This is not for postal addresses, but more in the case of I want to go somewhere in real life - in this case, we don't want the military states to be allowed, or PO Box 123 addresses. I would assume that the user, when setting up their addresses, would indicate whether they do or do not represent a physical location (assuming that a user can set up multiple addresses - it sounds like they can, based on the shipping vs. billing things) Fundamentally, I think we're going to have trouble if we try to use different fields in different places, and in particular if we use fields for specific localities. (That is, after all, why the given-name and family-name fields are bad.) Since we're not going to convince people to offer fields that are useless in most cases, we can't really add a boolean field just for France and its old colonies. Hence the convention to append CEDEX to the locality field. I think this is detectable enough that anyone doing data aggregation is going to have far fewer problems just filtering out the word CEDEX than they are dealing with any of the other data integrity issues (like the way people often use real towns instead of post towns in the UK, even when giving postal addresses). On Tue, 2 Jul 2013, Albert Bodenhamer wrote: Re the physical vs. mailing: This is not for postal addresses, but more in the case of I want to go somewhere in real life - in this case, we don't want the military states to be allowed, or PO Box 123 addresses. I would assume that the user, when setting up their addresses, would indicate whether they do or do not represent a physical location (assuming that a user can set up multiple addresses - it sounds like they can, based on the shipping vs. billing things) This sounds like something a browser could do if they wanted, but that doesn't need to be part of the spec. Agreed. On Thu, 4 Jul 2013, Lara Rennie wrote: Thanks Lara. So if browsers ask for CEDEX as a separate optional field and then append it to locality when filling would that be acceptable? I think that's where the spec is right now. I don't know if the merchants would expect this? Especially if they did want a separate field? What if they are using the (open-sourced) Google Address Widget? If they want a separate field, they can trivially just extract out the CEDEX bit by looking for the word CEDEX in the locality, and stripping it out if it's present. I would expect most implementations not to bother (since there doesn't seem to be any reason to -- just pretend the locality has CEDEX in the name, and it all works, no?). Re the physical vs. mailing: This is not for postal addresses, but more in the case of I want to go somewhere in real life - in this case, we don't want the military states to be allowed, or PO Box 123 addresses. I would assume that the user, when setting up their addresses, would indicate whether they do or do not represent a physical location (assuming that a user can set up multiple addresses - it sounds like they can, based on the shipping vs. billing things) This sounds like something a browser could do if they wanted, but that doesn't need to be part of the spec. I guess I was just meaning; if a site can use the spec to say please autocomplete with a shipping address for this user then they could also use it to say please autocomplete with a physical location for this user. But just an idea. Just because you might have two localities: one which is your post-town, and one which is your actual physical location. But shipping might cover this sufficiently. What's the use case? Right now we have shipping and billing as possible grouping keywords; we can certainly add more if there are compelling use cases. I don't think I've ever seen a form that asks for a shipping address and a physical address, though. Or billing and physical that isn't shipping. On Mon, 8 Jul 2013, Albert Bodenhamer wrote: I don't know if the merchants would expect this? Especially if they did want a separate field? What
Re: [whatwg] Proposal:Improve internationalization in the autocomplete attribute
On Thu, Jul 4, 2013 at 5:05 AM, Lara Rennie lararen...@google.com wrote: 2013/7/2 Albert Bodenhamer abode...@chromium.org On Thu, Jun 27, 2013 at 6:04 AM, Lara Rennie lararen...@google.comwrote: Sorry about the slow response, I was out on holiday. Re the CEDEX: it is a postal-code like thing, but it can't go in the postal-code field, or formatting would be bizarre; as pointed out, it should go after the locality field. However, if it was entered in the locality field, certain systems may complain about validation, anyone interested in aggregating data will start to get a lot of duplicate localities etc. It's also not just France - many ex-French colonies use this too. The Google Address Widget does actually accept CEDEX as a separate field; but you won't see this in most use-cases, because often the widget is used to collect a physical address (and then they disallow it), or it's used to give an address to a credit-card company (who are US based, and don't understand it or want things they don't understand...) Thanks Lara. So if browsers ask for CEDEX as a separate optional field and then append it to locality when filling would that be acceptable? I think that's where the spec is right now. I don't know if the merchants would expect this? Especially if they did want a separate field? Makes sense to me to break it out then. What if they are using the (open-sourced) Google Address Widget? Good point. I know Google forms use it extensively and others can too. I don't think it's currently marked with autocomplete attributes, but it would be great if it were. Re the physical vs. mailing: This is not for postal addresses, but more in the case of I want to go somewhere in real life - in this case, we don't want the military states to be allowed, or PO Box 123 addresses. I would assume that the user, when setting up their addresses, would indicate whether they do or do not represent a physical location (assuming that a user can set up multiple addresses - it sounds like they can, based on the shipping vs. billing things) This sounds like something a browser could do if they wanted, but that doesn't need to be part of the spec. I guess I was just meaning; if a site can use the spec to say please autocomplete with a shipping address for this user then they could also use it to say please autocomplete with a physical location for this user. But just an idea. Just because you might have two localities: one which is your post-town, and one which is your actual physical location. But shipping might cover this sufficiently. I don't have a strong opinion either way on this one. It sounds potentially useful, but I don't know if it's useful enough to justify addition to the spec. 2013/6/18 Albert Bodenhamer abode...@chromium.org Thanks Ian. Comments below. On Mon, Jun 17, 2013 at 4:27 PM, Ian Hickson i...@hixie.ch wrote: I was working on bug 22286, and noticed that this e-mail was relevant: On Tue, 11 Jun 2013, Albert Bodenhamer wrote: Address lines: Currently: Recommended handling for addresses is currently as a single line. Alternatively, sites can ask for address lines 1-3 but this is discouraged. Problem: Single line doesn't work well for all regions. Some areas have 5 lines for an address and might have more. Proposal: If address is requested as a single line newlines should be preserved when filling. Stop discouraging the use of address-lines. Support more than 3 lines for address. Potentially, address-lineX where X can be 1-9. Of these options, a multi-line street-address seems like the most reasonable, so I've gone with that. Cool. Address 'locality': Problem: Some regions have the concept of a post town. It's currently unclear how this should be requested. Proposal: Add post town to the list of expected localities in the description to make it more clear how this should be requested. Done. Sounds good. Address CEDEX codes: Problem: They don't fit well into the postal-code field and are often handled as a separate entity. Proposal: Add a field name for CEDEX code. Can you elaborate on this? The Wikipedia page for French postal addresses suggests that the CEDEX code is in fact the postal code, much like a PO Box number in the US is technically part of the 9-digit ZIP code, but that CEDEX is appended to the address' locality field. Lara, can you add more context here? You'd said that CEDEX doesn't really fit into postal code, but I don't understand why. Address: Physical vs mailing address Problem: It might be desirable to be able to specify that a physical address (an actual location) is expected rather than a mailing address (eg a PO box). Proposal: Open to suggestions. What's the use case? IMO this is a nice-to-have. Lara may disagree. The intent is that if the site needs a physical address it can specify that in the
Re: [whatwg] Proposal:Improve internationalization in the autocomplete attribute
On Thu, Jun 27, 2013 at 6:04 AM, Lara Rennie lararen...@google.com wrote: Sorry about the slow response, I was out on holiday. Re the CEDEX: it is a postal-code like thing, but it can't go in the postal-code field, or formatting would be bizarre; as pointed out, it should go after the locality field. However, if it was entered in the locality field, certain systems may complain about validation, anyone interested in aggregating data will start to get a lot of duplicate localities etc. It's also not just France - many ex-French colonies use this too. The Google Address Widget does actually accept CEDEX as a separate field; but you won't see this in most use-cases, because often the widget is used to collect a physical address (and then they disallow it), or it's used to give an address to a credit-card company (who are US based, and don't understand it or want things they don't understand...) Thanks Lara. So if browsers ask for CEDEX as a separate optional field and then append it to locality when filling would that be acceptable? I think that's where the spec is right now. Re the physical vs. mailing: This is not for postal addresses, but more in the case of I want to go somewhere in real life - in this case, we don't want the military states to be allowed, or PO Box 123 addresses. I would assume that the user, when setting up their addresses, would indicate whether they do or do not represent a physical location (assuming that a user can set up multiple addresses - it sounds like they can, based on the shipping vs. billing things) This sounds like something a browser could do if they wanted, but that doesn't need to be part of the spec. 2013/6/18 Albert Bodenhamer abode...@chromium.org Thanks Ian. Comments below. On Mon, Jun 17, 2013 at 4:27 PM, Ian Hickson i...@hixie.ch wrote: I was working on bug 22286, and noticed that this e-mail was relevant: On Tue, 11 Jun 2013, Albert Bodenhamer wrote: Address lines: Currently: Recommended handling for addresses is currently as a single line. Alternatively, sites can ask for address lines 1-3 but this is discouraged. Problem: Single line doesn't work well for all regions. Some areas have 5 lines for an address and might have more. Proposal: If address is requested as a single line newlines should be preserved when filling. Stop discouraging the use of address-lines. Support more than 3 lines for address. Potentially, address-lineX where X can be 1-9. Of these options, a multi-line street-address seems like the most reasonable, so I've gone with that. Cool. Address 'locality': Problem: Some regions have the concept of a post town. It's currently unclear how this should be requested. Proposal: Add post town to the list of expected localities in the description to make it more clear how this should be requested. Done. Sounds good. Address CEDEX codes: Problem: They don't fit well into the postal-code field and are often handled as a separate entity. Proposal: Add a field name for CEDEX code. Can you elaborate on this? The Wikipedia page for French postal addresses suggests that the CEDEX code is in fact the postal code, much like a PO Box number in the US is technically part of the 9-digit ZIP code, but that CEDEX is appended to the address' locality field. Lara, can you add more context here? You'd said that CEDEX doesn't really fit into postal code, but I don't understand why. Address: Physical vs mailing address Problem: It might be desirable to be able to specify that a physical address (an actual location) is expected rather than a mailing address (eg a PO box). Proposal: Open to suggestions. What's the use case? IMO this is a nice-to-have. Lara may disagree. The intent is that if the site needs a physical address it can specify that in the request. For example, if a shipper can't do PO box, singing telegrams, etc. I think this is something the user should be able to decide from context when selecting an address, but having extra constraints would be convenient. Phone: Problem: The detail sections for phone number are very US-centric. The spec discourages the use of the detail sections as a result, but sites may want to get phone number broken into chunks. Proposal: Consider adding additional detail sections to reduce the US bias. I'd much rather just drop the detailed sections entirely. People really shouldn't be using them, in any region. Sounds good to me. I haven't seen anyone wanting to break things apart yet. We can discuss further if someone has an actual use case. Thanks. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' -- Albert Bodenhamer | Software Engineer |
Re: [whatwg] Proposal:Improve internationalization in the autocomplete attribute
On 11/06/13 23:46, Albert Bodenhamer wrote: Address CEDEX codes: Problem: They don't fit well into the postal-code field and are often handled as a separate entity. Proposal: Add a field name for CEDEX code. As far as I can tell, CEDEX is never explicitly asked in French web forms. Likely because usually only organisations (companies, school, administrations) use such things and real people only use it when they have to send paper letters to those. I guess that someone that needs to fill out an address with a CEDEX will whether add it to the post code, the city name or simply not mention it. I doubt it is needed to add a new autocomplete value for that given that I doubt that forms have a field for that. -- Mounir
Re: [whatwg] Proposal:Improve internationalization in the autocomplete attribute
On Thu, 20 Jun 2013 17:31:42 +0200, Mounir Lamouri mou...@lamouri.fr wrote: On 11/06/13 23:46, Albert Bodenhamer wrote: Address CEDEX codes: Problem: They don't fit well into the postal-code field and are often handled as a separate entity. Proposal: Add a field name for CEDEX code. As far as I can tell, CEDEX is never explicitly asked in French web forms. Likely because usually only organisations (companies, school, administrations) use such things and real people only use it when they have to send paper letters to those. Which is not qiute as uncommon as it seems. Mostly, when real people who work in those organisations (companies, schools, and administrations are collectively responsible for a lot of employment in France) have to give a postal address - e.g. to buy physical things, or get real papers delivered to them. I guess that someone that needs to fill out an address with a CEDEX will whether add it to the post code, the city name or simply not mention it. Yeah, when I had to use it (about every second day for a few years) I just added it to the city name. I doubt it is needed to add a new autocomplete value for that given that I doubt that forms have a field for that. I can live with that. cheers -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: [whatwg] Proposal:Improve internationalization in the autocomplete attribute
On Thu, Jun 20, 2013 at 9:15 AM, Charles McCathie Nevile cha...@yandex-team.ru wrote: On Thu, 20 Jun 2013 17:31:42 +0200, Mounir Lamouri mou...@lamouri.fr wrote: On 11/06/13 23:46, Albert Bodenhamer wrote: Address CEDEX codes: Problem: They don't fit well into the postal-code field and are often handled as a separate entity. Proposal: Add a field name for CEDEX code. As far as I can tell, CEDEX is never explicitly asked in French web forms. Likely because usually only organisations (companies, school, administrations) use such things and real people only use it when they have to send paper letters to those. Which is not qiute as uncommon as it seems. Mostly, when real people who work in those organisations (companies, schools, and administrations are collectively responsible for a lot of employment in France) have to give a postal address - e.g. to buy physical things, or get real papers delivered to them. I guess that someone that needs to fill out an address with a CEDEX will whether add it to the post code, the city name or simply not mention it. Yeah, when I had to use it (about every second day for a few years) I just added it to the city name. Thanks for the extra info. It sounds like how it's used is ambiguous, that it's not important enough to justify its own field, but that when it's needed it's not clear where it should go. I'm a bit concerned about the inconsistency of it. I don't think we need a separate field for it, but it would be nice to be explicit about how it'll be handled if the browser is aware of it. I doubt it is needed to add a new autocomplete value for that given that I doubt that forms have a field for that. I can live with that. cheers -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com -- Albert Bodenhamer | Software Engineer | abodenha@chromium.abode...@google.com org
Re: [whatwg] Proposal:Improve internationalization in the autocomplete attribute
On Thu, 20 Jun 2013, Albert Bodenhamer wrote: I'm a bit concerned about the inconsistency of it. I don't think we need a separate field for it, but it would be nice to be explicit about how it'll be handled if the browser is aware of it. I updated the spec to be explicit about this. Let me know if it's still ambiguous. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal:Improve internationalization in the autocomplete attribute
I was working on bug 22286, and noticed that this e-mail was relevant: On Tue, 11 Jun 2013, Albert Bodenhamer wrote: Address lines: Currently: Recommended handling for addresses is currently as a single line. Alternatively, sites can ask for address lines 1-3 but this is discouraged. Problem: Single line doesn't work well for all regions. Some areas have 5 lines for an address and might have more. Proposal: If address is requested as a single line newlines should be preserved when filling. Stop discouraging the use of address-lines. Support more than 3 lines for address. Potentially, address-lineX where X can be 1-9. Of these options, a multi-line street-address seems like the most reasonable, so I've gone with that. Address 'locality': Problem: Some regions have the concept of a post town. It's currently unclear how this should be requested. Proposal: Add post town to the list of expected localities in the description to make it more clear how this should be requested. Done. Address CEDEX codes: Problem: They don't fit well into the postal-code field and are often handled as a separate entity. Proposal: Add a field name for CEDEX code. Can you elaborate on this? The Wikipedia page for French postal addresses suggests that the CEDEX code is in fact the postal code, much like a PO Box number in the US is technically part of the 9-digit ZIP code, but that CEDEX is appended to the address' locality field. Address: Physical vs mailing address Problem: It might be desirable to be able to specify that a physical address (an actual location) is expected rather than a mailing address (eg a PO box). Proposal: Open to suggestions. What's the use case? Phone: Problem: The detail sections for phone number are very US-centric. The spec discourages the use of the detail sections as a result, but sites may want to get phone number broken into chunks. Proposal: Consider adding additional detail sections to reduce the US bias. I'd much rather just drop the detailed sections entirely. People really shouldn't be using them, in any region. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal:Improve internationalization in the autocomplete attribute
Thanks Ian. Comments below. On Mon, Jun 17, 2013 at 4:27 PM, Ian Hickson i...@hixie.ch wrote: I was working on bug 22286, and noticed that this e-mail was relevant: On Tue, 11 Jun 2013, Albert Bodenhamer wrote: Address lines: Currently: Recommended handling for addresses is currently as a single line. Alternatively, sites can ask for address lines 1-3 but this is discouraged. Problem: Single line doesn't work well for all regions. Some areas have 5 lines for an address and might have more. Proposal: If address is requested as a single line newlines should be preserved when filling. Stop discouraging the use of address-lines. Support more than 3 lines for address. Potentially, address-lineX where X can be 1-9. Of these options, a multi-line street-address seems like the most reasonable, so I've gone with that. Cool. Address 'locality': Problem: Some regions have the concept of a post town. It's currently unclear how this should be requested. Proposal: Add post town to the list of expected localities in the description to make it more clear how this should be requested. Done. Sounds good. Address CEDEX codes: Problem: They don't fit well into the postal-code field and are often handled as a separate entity. Proposal: Add a field name for CEDEX code. Can you elaborate on this? The Wikipedia page for French postal addresses suggests that the CEDEX code is in fact the postal code, much like a PO Box number in the US is technically part of the 9-digit ZIP code, but that CEDEX is appended to the address' locality field. Lara, can you add more context here? You'd said that CEDEX doesn't really fit into postal code, but I don't understand why. Address: Physical vs mailing address Problem: It might be desirable to be able to specify that a physical address (an actual location) is expected rather than a mailing address (eg a PO box). Proposal: Open to suggestions. What's the use case? IMO this is a nice-to-have. Lara may disagree. The intent is that if the site needs a physical address it can specify that in the request. For example, if a shipper can't do PO box, singing telegrams, etc. I think this is something the user should be able to decide from context when selecting an address, but having extra constraints would be convenient. Phone: Problem: The detail sections for phone number are very US-centric. The spec discourages the use of the detail sections as a result, but sites may want to get phone number broken into chunks. Proposal: Consider adding additional detail sections to reduce the US bias. I'd much rather just drop the detailed sections entirely. People really shouldn't be using them, in any region. Sounds good to me. I haven't seen anyone wanting to break things apart yet. We can discuss further if someone has an actual use case. Thanks. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' -- Albert Bodenhamer | Software Engineer | abodenha@chromium.abode...@google.com org
Re: [whatwg] Proposal:Improve internationalization in the autocomplete attribute
On Mon, 17 Jun 2013, Albert Bodenhamer wrote: Problem: It might be desirable to be able to specify that a physical address (an actual location) is expected rather than a mailing address (eg a PO box). The intent is that if the site needs a physical address it can specify that in the request. For example, if a shipper can't do PO box, singing telegrams, etc. I think this is something the user should be able to decide from context when selecting an address, but having extra constraints would be convenient. In principle I agree, but I don't understand how this would work in practice. How would the UA find out that a particular address was or was not a physical address? We do already have shipping and billing addresses, for what it's worth. Also, note that the distinction between physical and mailing addresses is kind of fuzzy -- I know of physical addresses that UPS can ship to, but USPS cannot (or will not) deliver to; addresses that are true PO boxes but that appear (and act) like physical addresses (e.g. UPS can ship to them, their address doesn't mention PO BOX on it); addresses that are not PO boxes where USPS can deliver packages and letters but where UPS cannot (or at least not reliably); and so on. And let's not talk about special cases like military mail. I'd much rather just drop the detailed sections entirely. People really shouldn't be using them, in any region. Sounds good to me. I haven't seen anyone wanting to break things apart yet. We can discuss further if someone has an actual use case. When I suggested it before, the argument that was made was that a lot of sites do split the fields up in the US, and the strong recommendation that people use the single fields was the compromise we reached. I've left the fields in for now. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
