This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Some locales (e.g. China) sometimes use more than two administrative divisions in postal addresses. To resolve this, based on a long WHATWG thread, it is proposed that we change the spec as follows: rename "region" to "address-level1", add "region" as a synonym rename "locality" to "address-level2", add "locality" as a synonym add a field "address-level3" add a field "address-level4" adjust definitions for these fields accordingly add prose saying that different locales have different numbers of levels and that as many should be included as are appropriate given the country, starting with level1 as the widest administrative division.
Matt, can you comment on what you think of this proposal, as an implementor?
Note that Mozilla hasn't had autofill since the Mozilla Suite days (with "wallet") IIRC so I don't really have implementation opinions on this yet but it seems reasonable. We do have autocomplete using form history but this doesn't use @autocomplete yet. Brian Nicholson is working on requestAutocomplete so I'll let him comment on this though he doesn't have an account here yet.
ping Brian.
Just a quick note that we discussed this and were leaning towards not having the synonym since it can be confusing when level2 isn't really a "locality" e.g. it seems in Russia level 2 would be a sub-region and level 3 would be the locality. Then if we don't have a synonym for "locality", there isn't a strong reason to have one for "region". Brian might have more to add. Adding levels 3 and 4 plus the additional prose is definitely fine with us IIRC.
What does it mean to not have the synonym?
(In reply to Ian 'Hixie' Hickson from comment #5) > What does it mean to not have the synonym? Removing "region" and "locality" from the spec and just having the 4 levels.
As Matt said, the "region" and "locality" synonyms seem unnecessary. Maybe I'm in the minority, but if I were developing a form using these attributes, "region" and "locality" are vague enough that I'd have to look up their meanings in the spec anyway; at that point, I might as well just be using "address-level1" and "address-level2". Having "region" and "locality" as synonyms complicates things without much apparent benefit. Synonyms aside, this proposal seems reasonable to us. Also, I realize this has no bearing on the spec, but since Evan has pointed us to libaddressinput several times, we were hoping you might be able to clear something up for us. You said China currently has three administrative levels, but in this CN query [1], the "requires" property shows only "ACSZ". Those are "address", "city", "area", and "zip", which include only two administrative levels (city and area). Is this API incomplete, or are we misunderstanding something? We were considering using libaddressinput to help implement this feature, but maybe that's not an option. [1] http://i18napis.appspot.com/address/data/CN
Ah, interesting. IIRC, there were several reasons to keep those keywords: apparently Chrome would keep implementing them anyway, so it would be best to define how they worked; in some locales like the US it would be clearer to authors if they had names rather than levels; and finally, it would match legacy formats like hCard. Those weren't particularly strong reasons, though.
> Also, I realize this has no bearing on the spec, but since Evan has pointed > us to libaddressinput several times, we were hoping you might be able to > clear something up for us. You said China currently has three administrative > levels, but in this CN query [1], the "requires" property shows only "ACSZ". > Those are "address", "city", "area", and "zip", which include only two > administrative levels (city and area). Is this API incomplete, or are we > misunderstanding something? We were considering using libaddressinput to > help implement this feature, but maybe that's not an option. > > [1] http://i18napis.appspot.com/address/data/CN I'm not entirely sure, but I think the answer might be "not every address in China has the same number of levels". I'll ask the library's maintainers where you should direct this sort of question.
here's a list for asking questions: https://groups.google.com/forum/#!forum/libaddressinput-discuss
Evan, is there content using region/locality that we can't get changed? Or is just renaming ok? (If Chrome is going to keep supporting region/locality regardless, then that implies that just renaming is not ok for you.)
For requestAutocomplete, renaming is not a problem, because we could get those sites to change. But Chrome has supported the current autocomplete="" attributes for a long time (~2 years?), and Google has been preaching the autocomplete gospel since before requestAutocomplete. I don't know how much these types are used in the wild, but randomly breaking sites with little hope of the author noticing and fixing it is probably a negative user experience. That said, I'm sure there's precedent for making breaking changes, so we should follow that precedent, whatever it is.
The precedent is never break anything, basically. Brian, given the likely existence of legacy content with these field names, could you live with the synonyms?
(In reply to Ian 'Hixie' Hickson from comment #8) > …it would match legacy formats like hCard. Except that we're adding levels 3 and 4 which already diverges from hCard (although some sites may not care about countries with more than two levels). (In reply to Evan Stade from comment #12) > Google has been preaching the autocomplete gospel since before > requestAutocomplete. Were these two values ('locality' and 'region') part of this preaching? Where were these values documented? (In reply to Ian 'Hixie' Hickson from comment #13) > The precedent is never break anything, basically. In this case we're talking about an experimental extension to HTML that was only used by one UA. These values probably should have been prefixed or put behind a flag to avoid the possible compatibility issue. Arguments for removal of the synonyms: 1) The synonyms are incorrect in some countries (see comment 4). 2) It's unclear that the values of "locality" and "region" provide more benefit than the confusion they cause for developers (see comment 7). 3) We don't think the implementation complexity of synonyms is warranted. 4) We won't be supporting them. Chrome can keep supporting them with a console warning if they feel the need. I think authors will test their sites in Firefox when we announce our implementation of rAc and they will quickly notice if they were using these two values. The sooner these values are removed from the spec, the less of a compatibility issue there will be IMO. If they are removed from the spec, the worst case is that we add them to Gecko and the spec if we see major breakage that doesn't get addressed by authors. If Chrome adds a deprecation warning shortly, that will make the worst case less likely.
(Quoting Matthew Noorenberghe from comment #14) > Arguments for removal of the synonyms: > … 5) Authors may use the locality and region synonyms without realizing that they will be missing data in some countries where levels 3 and/or 4 are also needed. When using "address-level1" and "address-level2", it's obvious that there may be levels that follow and those levels would appear adjacent to 1 and 2 in most lists. In other words, this may encourage a bad pattern.
(In reply to Matthew Noorenberghe from comment #14) > (In reply to Ian 'Hixie' Hickson from comment #8) > > …it would match legacy formats like hCard. > > Except that we're adding levels 3 and 4 which already diverges from hCard > (although some sites may not care about countries with more than two levels). > > (In reply to Evan Stade from comment #12) > > Google has been preaching the autocomplete gospel since before > > requestAutocomplete. > > Were these two values ('locality' and 'region') part of this preaching? > Where were these values documented? Yes. They've been in the standard since 2012 I believe: http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#attr-fe-autocomplete > 4) We won't be supporting them. Chrome can keep supporting them with a > console warning if they feel the need. I think authors will test their sites > in Firefox when we announce our implementation of rAc and they will quickly > notice if they were using these two values. The compatibility problem comes from the sites that already exist and use autocomplete attributes but don't use rAc. They won't notice the change because they won't be explicitly testing in Firefox.
(In reply to Evan Stade from comment #16) > The compatibility problem comes from the sites that already exist and use > autocomplete attributes but don't use rAc. They won't notice the change > because they won't be explicitly testing in Firefox. My current proposal is to ship rAc before any manual auto-fill feature so this wouldn't be a problem for us initially (assuming we go with that proposal).
If they had been prefixed, the prefixes is what I would have put into the spec. So that wouldn't have helped. :-) If Mozilla won't support these, but Chrome will, I'm in a tough spot, spec-wise. So far I've found one site that uses this: http://americamagazine.org/user/register The problem is that most places that use this would use it on their checkout page, which I won't find via automated search. FWIW, I also found that Drupal is using markup like this a lot (note the use of autocomplete on <div>s): <div class='contact-right-rail'> <div class="right-rail-header"> <div class="field-item even">FMCSA Information Line</div> </div> <div class="contact-full-name" ></div> <div class="contact-title"></div> <div class="contact-division"></div> <div class="contact-address"><div class="field field-name-field-address field-type-addressfield field-label-hidden"><div class="field-items"><div class="field-item even"><div class="street-block"><div class="thoroughfare" x-autocompletetype="address-line1" autocomplete="address-line1">1200 New Jersey Avenue SE</div></div><div class="addressfield-container-inline locality-block country-US"><span class="locality" x-autocompletetype="locality" autocomplete="locality">Washington</span>, <span class="state" x-autocompletetype="region" autocomplete="region">DC</span> <span class="postal-code" x-autocompletetype="postal-code" autocomplete="postal-code">20590</span></div><span class="country" x-autocompletetype="country" autocomplete="country">United States</span></div></div></div></div> <div class="contact-address"></div> <div class="contact-phone-numbers"> <div> Phone: 800-832-5660 </div> <div> </div> <div> </div> <div> </div> </div>
I did more research on this, and I'm starting to think we can probably drop region and locality without much pain at all. Maybe Chrome should try adding a UseCounter, to see how much this really impacts anyone? It certainly would make life easier if we didn't have to have any synonyms. What I found was that the only sites that used autocomplete="region" at all were Drupal sites. Most of them used it in the utterly bogus fashion described above; the remainder, less than a thousand pages on less than 200 domains (over half the pages on just one of those domains), did use it on form fields. Here's a sampling of the ones that are real: http://www.campsinternational.com/jobs - scroll to bottom, check "Tick to receive a brochure in the post" to reveal the address form fields with region/locality. This domain is responsible for the bulk of the pages on the open Web that use autocomplete="region" correctly. http://www.robertorevillalondon.com/ - click "request an appointment" https://www.hamilton-trust.org.uk/user/login http://www.halogolf.com/user/login on these, click "I want to create an account" to reveal the address form fields with region/locality https://stakesandladders.com/user/register http://www.aetg.es/user/register https://triplecheckaccountants.co.uk/user/register https://register.wacom.asia/user/register http://www.4matrix.com/order https://alpha.sonyapps.in/user/register http://www.na3t.net/user/register http://companyofanimals.co.uk/user/register on these, just scroll down to find the address part of the form. As noted before, though, this doesn't take into account pages that are hidden behind checkout flows, which I could believe are the majority of uses of the autocomplete="region" value. A UseCounter would help settle that issue.
The closest metric Chrome has just measures how many forms use any autocomplete="type" (off and on not included). The answer is under 0.1% of forms that Chrome encounters, although that is still many forms.
I don't know how to progress on this. What information would make either of you change your mind about whether to implement or not implement region/locality?
There must be precedent for how to deprecate a feature. I wouldn't want to turn off "region" without warning, but we could provide a period of time where both new and old work while region/locality logs a warning to the dev console. This grace period can exist outside the spec, no? i.e. just remove them from the spec, and let Chrome handle gradual turn down of region/locality.
I believe Chrome has a deprecation plan. If you're willing to do that, then that would solve the problem — it would mean that Chrome doesn't support both on the medium term.
I don't know the exact definition of "medium term" but I'm fine with deprecating and eventually removing locality/region.
Ok. New plan, then: rename "region" to "address-level1" rename "locality" to "address-level2" add a field "address-level3" add a field "address-level4" adjust definitions for these fields accordingly add prose saying that different locales have different numbers of levels and that as many should be included as are appropriate given the country, starting with level1 as the widest administrative division. Is that ok with everyone?
That looks good to me.
yep.
Let me know if I missed anything, or if any of the examples are wrong. I tried to make sure they were right per Wikipedia, but...
Checked in as WHATWG revision r8654. Check-in comment: Change how addresses are marked up for autofill, since some locales don't fit the region/locality split http://html5.org/tools/web-apps-tracker?from=8653&to=8654
Checked in as WHATWG revision r8655. Check-in comment: fix typo in last checkin http://html5.org/tools/web-apps-tracker?from=8654&to=8655