- From: Albert Bodenhamer <abodenha@chromium.org>
- Date: Tue, 2 Jul 2013 09:42:56 -0700
- To: Lara Rennie <lararennie@google.com>
- Cc: whatwg@whatwg.org, Ian Hickson <ian@hixie.ch>
On Thu, Jun 27, 2013 at 6:04 AM, Lara Rennie <lararennie@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 <abodenha@chromium.org> > >> Thanks Ian. Comments below. >> >> >> On Mon, Jun 17, 2013 at 4:27 PM, Ian Hickson <ian@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.<abodenha@google.com> >> org >> > > -- Albert Bodenhamer | Software Engineer | abodenha@chromium.<abodenha@google.com> org
Received on Tuesday, 2 July 2013 16:43:44 UTC