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.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. >> > > 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 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 >>>> >>> >>> >> >> >> -- >> Albert Bodenhamer | Software Engineer | >> abodenha@chromium.<abode...@google.com> >> org >> > > -- Albert Bodenhamer | Software Engineer | abodenha@chromium.<abode...@google.com> org
