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 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. I just tried the Google address widget, and I have to be honest, I don't understand the way it uses the CEDEX field. It seems to be a free-form text field, which makes no sense to me. Are we sure people in locales that use CEDEX won't find it more intuitive to add it after the locality, the way it is written on envelopes? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
