Re: [whatwg] PSA: Chrome ignoring autocomplete="off" for Autofill data
On Thu, Nov 13, 2014 at 11:42 PM, Roger Hågensen wrote: > On 2014-11-14 08:02, Evan Stade wrote: > >> On Thu, Nov 13, 2014 at 5:17 PM, Roger Hågensen >> wrote: >> >> On 2014-11-13 20:20, Evan Stade wrote: >>> >>> Currently this new behavior is available behind a flag. We will soon be >>>> inverting the flag, so you have to opt into respecting >>>> autocomplete="off". >>>> >>>> >>>> I don't like that browsers ignore HTML functionality hints like that. >>> >>> I have one real live use case that would be affected by this. >>> http://player.gridstream.org/request/ >>> This radio song request uses autocomplete="off" for the music request >>> because a listener would probably not request the same bunch of songs >>> over >>> and over. >>> >>> autocomplete="off" will still be respected for autocomplete data. This >> should cover your use case. >> >> >> Also, banks generally prefer to have autocomplete="off" for credit card >>> numbers, names, addresses etc. for security reasons. And that is now to >>> be >>> ignored? >>> >>> I'm not sure what security threat is addressed by respecting >> autocomplete="off". >> > > SSN, PIN, and so on. > Sure, it's the users responsibility to ensure their PC/laptop/tablet is > secured. > But it's very quick to press 0-9 and you got a pin, that being said a bank > should have two factor anyway (or better), and pins can be changed. SSN > can not though. Also the government is pretty strict in Norway on the > leaking of SSN (here's it called Personal Number though) and in that case > they start with 0-9 so it's quick to get the autocomplete to spit it out. > > This is also autocomplete, not Autofill (in Chrome parlance). >> > > In that case, my mistake, autocomplete, autofill, autosuggest, input > history, it all kind of blurs together, so apologies for that. > > Would there be any point in having a per FORM autofill on/off instead? > autocomplete="off" can already be applied to a form as well as an input > That way if a autofill="off" is set for the form itself then the user > could be prompted "This site wishes to not store any form data, Agree? Yes! > No" and then have the browser remember the choice the user made (so the > next time based on the user choice, the form is either autofilled or not). > and maybe word it better than I did there. > And if the autofill="off" hint is missing (or set to "on") then the user > is never prompted. > > This would give even more power to the user than currently. The problem is that we don't think autocomplete="off" is used judiciously. There's no particular correlation with risk to the user. The user is not going to be able to make an informed choice in response to that prompt, and it's added friction. > > If it was my bank I would probably (if shown such a prompt) prefer to not > have anything autofilled or autocompleted. > But if it was a comment form on a blog I'd probably want that (autofilled > and/or autocomplete etc). > As a user I should be able to choose that easily. (digging around in > advanced settings is not what I'd call easy.) > The key though is it defaults to autofill and the user prompt only appears > if autofill="off" is set as a parameter for the form, and the user choice > is remembered. > > Geolocation data is prompted for in a similar way as to what I describe > here right? Chrome Autofill already prompts the user in the form of a dropdown. If the user doesn't want to share information with the site, they shouldn't select one of the rows in the dropdown. A second prompt is not going to add value. > > > > -- > Roger "Rescator" Hågensen. > Freelancer - http://www.EmSai.net/ > >
Re: [whatwg] PSA: Chrome ignoring autocomplete="off" for Autofill data
That sounds like crbug.com/354257 which was fixed in March. Are you sure this is still a problem on newer versions of Chrome? On Thu, Nov 13, 2014 at 8:22 PM, Igor Minar wrote: > Are you going to properly fire change&input events when autofill happens? > > The current autofill behavior is causing major headaches for application > and framework developers and by ignoring autocomplete attribute you disable > the only way developers can work around this bug. > > On angular we had to developer a special hack in an attempt to fix it, but > it's far from ideal: > https://github.com/angular/angular.js/issues/1460#issuecomment-33837127 > > The browser should let DOM know when autofill happens, so apps can treat > user input and autofill as the same. Right now this is not the case and it > sounds like you are going to make it only worse. > > \i > > > > On Thu Nov 13 2014 at 11:20:28 AM Evan Stade wrote: > >> Hi, >> >> Chrome already ignores the prevalent autocomplete="off" for password >> fields. We plan to ignore this tag for Autofill (addresses, credit cards) >> fields as well. autocomplete="off" will still be respected for >> autocomplete >> data (e.g. past searches on crbug.com). >> >> We think this will break a very small number of sites that use >> autocomplete="off" for legitimate reasons, e.g. they use the Google Maps >> Places Autocomplete API, and don't want Chrome trying to autofill in >> addition. But it will improve behavior for a much larger set of sites >> which >> use autocomplete="off" for confused reasons as a part of, e.g., their >> checkout flow. We have found the prevalence of autocomplete="off" in top >> sites' checkout forms to be quite high. >> >> Currently this new behavior is available behind a flag. We will soon be >> inverting the flag, so you have to opt into respecting autocomplete="off". >> >> I am curious what other browsers do around autocomplete="off", and if they >> respect it for address/user profile/credit card type data. Since there's >> no >> way to feature detect the browser's behavior, it would be convenient if >> all >> browsers agreed on the meaning/value of the attribute. >> >> -- Evan Stade >> >
Re: [whatwg] PSA: Chrome ignoring autocomplete="off" for Autofill data
On Thu, Nov 13, 2014 at 5:17 PM, Roger Hågensen wrote: > On 2014-11-13 20:20, Evan Stade wrote: > >> Currently this new behavior is available behind a flag. We will soon be >> inverting the flag, so you have to opt into respecting autocomplete="off". >> >> > I don't like that browsers ignore HTML functionality hints like that. > > I have one real live use case that would be affected by this. > http://player.gridstream.org/request/ > This radio song request uses autocomplete="off" for the music request > because a listener would probably not request the same bunch of songs over > and over. > autocomplete="off" will still be respected for autocomplete data. This should cover your use case. > Also the reason the name field also has autocomplete="off" is simple, if > somebody uses a public terminal then not having the name remembered is nice. > Only the user can figure out if they're at a public terminal. > > Also, banks generally prefer to have autocomplete="off" for credit card > numbers, names, addresses etc. for security reasons. And that is now to be > ignored? > I'm not sure what security threat is addressed by respecting autocomplete="off". > > > Also note that in Norway this month a lot of banks are rolling out BankID > 2.0 which does not use Java, instead they use HTML5 tech. > And even todays solution (like in my bank) login is initiated by entering > my social ID number, which is entered into a input field with the text with > autocompelete="off". > Now my computer I have full control over but others may not (work place > computer, they walk off for a coffee) and someone could walk by and type > the first digit 0-9 and see whatever social id numbers had been entered. > This is also autocomplete, not Autofill (in Chrome parlance).
[whatwg] PSA: Chrome ignoring autocomplete="off" for Autofill data
Hi, Chrome already ignores the prevalent autocomplete="off" for password fields. We plan to ignore this tag for Autofill (addresses, credit cards) fields as well. autocomplete="off" will still be respected for autocomplete data (e.g. past searches on crbug.com). We think this will break a very small number of sites that use autocomplete="off" for legitimate reasons, e.g. they use the Google Maps Places Autocomplete API, and don't want Chrome trying to autofill in addition. But it will improve behavior for a much larger set of sites which use autocomplete="off" for confused reasons as a part of, e.g., their checkout flow. We have found the prevalence of autocomplete="off" in top sites' checkout forms to be quite high. Currently this new behavior is available behind a flag. We will soon be inverting the flag, so you have to opt into respecting autocomplete="off". I am curious what other browsers do around autocomplete="off", and if they respect it for address/user profile/credit card type data. Since there's no way to feature detect the browser's behavior, it would be convenient if all browsers agreed on the meaning/value of the attribute. -- Evan Stade
Re: [whatwg] Various autocomplete="" topics
Regarding transaction-amount and transaction-currency: is there consensus that they are useful types? Should the discussion move to a bug? They are mentioned here[1] but they aren't the main topic of that bug. [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25471 -- Evan Stade On Tue, May 6, 2014 at 6:25 PM, Evan Stade wrote: > Dunno if you still wanted answers to these questions, but in order to not > leave you hanging here are my best attempts: > > >> >> >> On Tue, 4 Mar 2014, Evan Stade wrote: >> > >> > "dependent-locality" and "locality" have a fairly precise meaning in the >> > UK. Also in a natural-language conversation, if you ask me what "region" >> > of the country I live in, I'd say "New England", "the Midwest", or some >> > such; certainly not the state where I reside. The descriptions for these >> > tokens are currently pretty specific, for example they say a city would >> > be a locality. But this is not true for Beijing or some other cities. To >> > fix the descriptions, we'd have to change them to something like >> > "region: the highest level administrative region below country in the >> > address" and "locality: the second-highest level administrative region >> > below country in the address", "sub-locality: the third-highest level >> > administrative region [...]". >> >> With you so far. >> >> >> > At this point, one wonders why the tokens aren't just [something]1, >> > [something]2, etc. >> >> I don't understand how you get there. Why would you wonder this? >> > > Because if the long, more descriptive copy is "first highest," "second > highest," etc., it follows that the concise description (i.e. the type > name) match that. > > >> >> >> > > > > > > > >"address-line1" | >> > > > > > > > >"address-line2" |- "street-address" >> > > > > > > > >"address-line3" | >> > > > > > > > >"locality" >> > > > > > > > >"subsubregion" >> > > > > > > > >"subregion" >> > > > > > > > >"region" >> > > > > > > > >"country-name" >> > > >> > > I don't understand why you think authors will think they need to >> > > include "subregion", but won't think they need to include >> > > "address-level3". >> > >> > I think they'll assume subregion returns something for the US if it's >> > sandwiched between "region" and "locality", because county is in between >> > state and city. But in reality, subregion will return nothing. >> >> But why does this not apply to the numeric version? >> > > Because address-level1 is state and address-level2 is city, so there's no > implication of something in between them. > > >> >> > > > Why is that better than 1=region, 2=locality, except to a US-centric >> > > > viewpoint? This would lead to a weird situation where (a) you >> > > > couldn't expand past 4 levels without changing the meaning of >> > > > previous levels and (b) a country such as the US would have >> > > > address-level4 and address-level3 but no address-level2 or >> > > > address-level1. >> > > >> > > Well, at least as far as (a) goes, we have no way to know where >> > > governments are going to introduce new levels. Who's to say that the >> > > US won't introduce something between states and towns? This problem >> > > exists whatever we do. Maybe the US and the EU will merge and there'll >> > > be a new field between "country-name" and "region". Who knows. >> > >> > One can dream... >> > >> > You're right that changing political circumstances might put us in an >> > awkward situation no matter what we do. But it seems to me the most >> > likely scenario is that a government would add more administrative >> > levels at the most granular level. >> >> Why? It seems just as likely that we'll add levels between "country" and >> "region". For instance, the example above. > > Or, in a few years, when there >> are parts of countries in space, maybe there'll be a planetoid name >> between the country and the region. Or maybe that will go on the other >> side of the country. > > >> I think trying to guess how things will be extended is a fool's errand. >> >> If we use numbers, we paint ourselves into a corner with extensions >> anywhere but at the deepest level. >> > > Well what do we do with words? Add "subsubsubregion" or > "moderately-big-area" in between two existing words? > > If a country experiences political turmoil and changes the number of types > of administrative divisions it has, I guess it's reasonable to redefine > "level4" to the former "level3", and add a new "level5" which is the former > "level4". > > >> >> I've filed a bug on this topic; if I can get agreement from other vendors, >> then I'll go ahead and spec this: >> >>https://www.w3.org/Bugs/Public/show_bug.cgi?id=25235 > > > great! > >
Re: [whatwg] Various autocomplete="" topics
Dunno if you still wanted answers to these questions, but in order to not leave you hanging here are my best attempts: > > > On Tue, 4 Mar 2014, Evan Stade wrote: > > > > "dependent-locality" and "locality" have a fairly precise meaning in the > > UK. Also in a natural-language conversation, if you ask me what "region" > > of the country I live in, I'd say "New England", "the Midwest", or some > > such; certainly not the state where I reside. The descriptions for these > > tokens are currently pretty specific, for example they say a city would > > be a locality. But this is not true for Beijing or some other cities. To > > fix the descriptions, we'd have to change them to something like > > "region: the highest level administrative region below country in the > > address" and "locality: the second-highest level administrative region > > below country in the address", "sub-locality: the third-highest level > > administrative region [...]". > > With you so far. > > > > At this point, one wonders why the tokens aren't just [something]1, > > [something]2, etc. > > I don't understand how you get there. Why would you wonder this? > Because if the long, more descriptive copy is "first highest," "second highest," etc., it follows that the concise description (i.e. the type name) match that. > > > > > > > > > > >"address-line1" | > > > > > > > > >"address-line2" |- "street-address" > > > > > > > > >"address-line3" | > > > > > > > > >"locality" > > > > > > > > >"subsubregion" > > > > > > > > >"subregion" > > > > > > > > >"region" > > > > > > > > >"country-name" > > > > > > I don't understand why you think authors will think they need to > > > include "subregion", but won't think they need to include > > > "address-level3". > > > > I think they'll assume subregion returns something for the US if it's > > sandwiched between "region" and "locality", because county is in between > > state and city. But in reality, subregion will return nothing. > > But why does this not apply to the numeric version? > Because address-level1 is state and address-level2 is city, so there's no implication of something in between them. > > > > > Why is that better than 1=region, 2=locality, except to a US-centric > > > > viewpoint? This would lead to a weird situation where (a) you > > > > couldn't expand past 4 levels without changing the meaning of > > > > previous levels and (b) a country such as the US would have > > > > address-level4 and address-level3 but no address-level2 or > > > > address-level1. > > > > > > Well, at least as far as (a) goes, we have no way to know where > > > governments are going to introduce new levels. Who's to say that the > > > US won't introduce something between states and towns? This problem > > > exists whatever we do. Maybe the US and the EU will merge and there'll > > > be a new field between "country-name" and "region". Who knows. > > > > One can dream... > > > > You're right that changing political circumstances might put us in an > > awkward situation no matter what we do. But it seems to me the most > > likely scenario is that a government would add more administrative > > levels at the most granular level. > > Why? It seems just as likely that we'll add levels between "country" and > "region". For instance, the example above. Or, in a few years, when there > are parts of countries in space, maybe there'll be a planetoid name > between the country and the region. Or maybe that will go on the other > side of the country. > I think trying to guess how things will be extended is a fool's errand. > > If we use numbers, we paint ourselves into a corner with extensions > anywhere but at the deepest level. > Well what do we do with words? Add "subsubsubregion" or "moderately-big-area" in between two existing words? If a country experiences political turmoil and changes the number of types of administrative divisions it has, I guess it's reasonable to redefine "level4" to the former "level3", and add a new "level5" which is the former "level4". > > I've filed a bug on this topic; if I can get agreement from other vendors, > then I'll go ahead and spec this: > >https://www.w3.org/Bugs/Public/show_bug.cgi?id=25235 great!
Re: [whatwg] Various autocomplete="" topics
rowsers are moving away from respecting autocomplete=off. I don't think
> > we should be adding a new but basically equivalent mechanism.
>
> On Mon, 21 Apr 2014, Garrett Casto wrote:
> >
> > While I agree that it's a concern, I'm not overly worried that this is
> > going to be abused for a few reasons.
> >
> > 1) We talked to some major US banks when disabling autocomplete=off for
> > passwords, and though they historically have been a big proponent of the
> > feature they didn't seem bothered that it was no longer going to be
> > respected. It seems like sites are more accepting of password managers
> > now. I wouldn't be surprised if a reasonable percentage of
> > autocomplete=off usage is just inertia at this point.
> >
> > 2) A well-intentioned site might use autocomplete=off thinking that it's
> > a security benefit to their site. Doing this with this new API would be
> > obvious abuse and it doesn't seem likely that a site would do it unless
> > they were looking for some way to block password managers. 3) If a site
> > really wants to go out of their way to make sure that password managers
> > don't work on their site, there are already ways of doing it. This would
> > be an easier mechanism, but I'm not sure how much that matters.
> >
> > If we still think that this is too likely to be abused, another
> > possibility might be to only allow the site to assert login succeeded
> > not that it failed. Not sure how useful that is though, since it's
> > generally easier to prompt on incorrect login than miss a correct login.
>
> I think the way to make progress on this issue would be for the vendors
> interested in deploying a solution to do so experimentally, and to see how
> authors use it.
>
>
> On Mon, 14 Apr 2014, Dan Beam wrote:
> >
> > I propose requestAutocomplete()[1] should return a Promise. This has
> > been requested since the creation of this API[2][3] and seems like a
> > natural fit. Web authors can then call requestAutocomplete() like this:
> >
> > form.requestAutocomplete().then(function() {
> > // form.submit() or some other success action
> > }, function(errorDetails) {
> > // handle error based on errorDetails.reason (e.g. "cancel")
> > });
> >
> > The returned promise would be resolved after the corresponding
> > "autocomplete" or "autocompleteerror" event is dispatched on the form.
> > [...]
>
> Fine by me.
>
> How stable is the whole promise world so far? Are any APIs using it yet?
>
> I tried using it in HTML before, but the API changed radically shortly
> afterwards, so I'm a bit reluctant to start specifying stuff again on this
> topic before other specs have done so.
>
>
> On Thu, 24 Apr 2014, Dan Beam wrote:
> >
> > Regarding the rejection argument: requestAutocomplete() can fail in a
> > way that doesn't map intuitively to the current DOMException names (e.g.
> > the invoking has autocomplete="off" or isn't in a frame).
> > Adding new names for these specific failure categories doesn't seem
> > useful to the platform. Additionally, many potential failure causes may
> > have the same reason property[1] ("disabled" => SecurityError,
> > WrongDocumentError?, InvalidAccessError?)** and the terminology differs
> > slightly ("cancel" => AbortError).
> >
> > This seems confusing to web authors, so I propose a new type instead (in
> > IDL):
> >
> > interface AutocompleteError : DOMException {
> > readonly attribute DOMString reason; // matches
> AutocompleteErrorEvent's reason
> > };
>
> On Fri, 25 Apr 2014, Boris Zbarsky wrote:
> >
> > In general, please check with public-script-coord before minting new
> > exception types; there's been a lot of discussion on that issue
> > recently.
>
> Please report back on the conclusion of this discussion on this bug:
>
>https://www.w3.org/Bugs/Public/show_bug.cgi?id=25472
>
> Thanks!
>
>
> On Wed, 23 Apr 2014, Brian Nicholson wrote:
> > On Mon, Mar 10, 2014 at 1:33 PM, Evan Stade wrote:
> > >
> > > Currently, requestAutocomplete lets a user agent provide the same user
> > > experience across multiple sites for common data input flows. A site
> > > describes the data it desires (via a form and autocomplete
> > > attributes), and the user agent uses this information and what it
> > > knows about the user to expedite data input. For example, if one of
> > > the form el
Re: [whatwg] Additional details for invoking requestAutocomplete
Also, in response to something Ian wrote on another thread: > Why would this only apply to requestAutocomplete()? Surely it would be > just as important for the case where the user agent is filling in a form > without using that API. That is true, but I don't know of a better way to convey this information from the page to browser. Additional attributes on the cc-number field? > Also, I don't understand how these are supposed to work. How is the > browser supposed to know the balance on my credit cards or bank accounts? > How is the browser supposed to know which of my cards are good for USD and > which are good for GBP? If the browser is just a dumb number memorizer, it probably won't, in which case it may return a card that denies the transaction. The new API doesn't /guarantee/ the returned card will work, it just increases the likelihood of a successful transaction. Conceptually, how the browser /could/ know the balance on the credit cards is if it pings some remote server to obtain this information, or if it remembers each card's credit limit (ignoring how much of the limit may have already been used), etc. -- Evan Stade On Wed, Apr 23, 2014 at 9:13 PM, Evan Stade wrote: > Specifically, Chromium would disable Wallet for transactions over a > certain limit (at the moment, that's $2k, but this business logic is > subject to change). When Wallet is disabled, users can still store/access > their data in Chrome/Chrome Sync. > > > -- Evan Stade > > > On Wed, Apr 23, 2014 at 5:02 PM, Brian Nicholson > wrote: > >> This optional argument sounds reasonable to me (FWIW, I'm working on >> the requestAutocomplete implementation for Firefox). The transaction >> fields also seem sensible, but I have no experience with payment APIs, >> so I can't give feedback on how well this will work with payment >> providers in general (and whether any additional fields might be >> useful). Those working on Mozilla's payment APIs are aware of this >> thread, so hopefully they'll be giving feedback if they have anything >> to add. >> >> When I first read this proposal, I was under the impression that the >> browser would somehow detect whether transactions would put users over >> their card limits, but maybe you're going for something simpler than >> that. Could you elaborate on how Chromium will handle these >> transactions differently? >> >> - Brian >> >> >> On Mon, Mar 10, 2014 at 1:33 PM, Evan Stade wrote: >> >> > Hi WhatWG. >> > >> > Currently, requestAutocomplete lets a user agent provide the same user >> > experience across multiple sites for common data input flows. A site >> > describes the data it desires (via a form and autocomplete attributes), >> and >> > the user agent uses this information and what it knows about the user to >> > expedite data input. For example, if one of the form elements has >> > autocomplete=”cc-number” the browser might provide an experience >> tailored >> > for a payment flow, or if there’s an element with autocomplete=”bday” >> the >> > browser might use an experience that’s tailored for sharing identiy. >> > >> > We’ve found that there are some details of the interaction which might >> > affect the UX which cannot be inferred from the data inputs. We propose >> to >> > add an optional argument to the requestAutocomplete method. Thus >> invocation >> > would look like: >> > >> > form_element. >> requestAutocomplete(details); >> > >> > This |details| argument would be an object where key-value pairs provide >> > additional details regarding the request. The spec should define a set >> of >> > keys and associated data types which are recognized. There are currently >> > two key-value pairs we would like to add: >> > >> > key: “transactionAmount” >> > value: number >> > description: For data that is going to be applied towards a >> > transaction, the /maximum/ value of the transaction. The browser does >> not >> > guarantee that the returned payment instrument will work, but keeping >> the >> > transaction under this amount will increase the likelihood of receiving >> a >> > valid card number. >> > >> > key: “transactionCurrency” >> > value: string >> > description: a valid ISO 4217 currency code that describes the >> > currency for transactionAmount. If not provided, the default is “USD”. >> > >> > Justification? There are upper bounds on certain payment instruments, >> for >> > example different credit cards have different credit limits; a debit >> card >> > is linked to a bank account with a certain balance. It’s a much >> preferable >> > user experience to be able to catch these problems earlier rather than >> > waiting for the merchant to attempt the transaction and have it fail (or >> > have a user’s account overdrawn). Concretely, Chromium wants to handle >> > transactions over $2000 differently from transactions under that amount. >> > >> > Does this seem reasonable? >> > >> > >> > -- Evan Stade >> > >> > >
Re: [whatwg] Additional details for invoking requestAutocomplete
Specifically, Chromium would disable Wallet for transactions over a certain limit (at the moment, that's $2k, but this business logic is subject to change). When Wallet is disabled, users can still store/access their data in Chrome/Chrome Sync. -- Evan Stade On Wed, Apr 23, 2014 at 5:02 PM, Brian Nicholson wrote: > This optional argument sounds reasonable to me (FWIW, I'm working on > the requestAutocomplete implementation for Firefox). The transaction > fields also seem sensible, but I have no experience with payment APIs, > so I can't give feedback on how well this will work with payment > providers in general (and whether any additional fields might be > useful). Those working on Mozilla's payment APIs are aware of this > thread, so hopefully they'll be giving feedback if they have anything > to add. > > When I first read this proposal, I was under the impression that the > browser would somehow detect whether transactions would put users over > their card limits, but maybe you're going for something simpler than > that. Could you elaborate on how Chromium will handle these > transactions differently? > > - Brian > > > On Mon, Mar 10, 2014 at 1:33 PM, Evan Stade wrote: > > > Hi WhatWG. > > > > Currently, requestAutocomplete lets a user agent provide the same user > > experience across multiple sites for common data input flows. A site > > describes the data it desires (via a form and autocomplete attributes), > and > > the user agent uses this information and what it knows about the user to > > expedite data input. For example, if one of the form elements has > > autocomplete=”cc-number” the browser might provide an experience tailored > > for a payment flow, or if there’s an element with autocomplete=”bday” the > > browser might use an experience that’s tailored for sharing identiy. > > > > We’ve found that there are some details of the interaction which might > > affect the UX which cannot be inferred from the data inputs. We propose > to > > add an optional argument to the requestAutocomplete method. Thus > invocation > > would look like: > > > > form_element. > requestAutocomplete(details); > > > > This |details| argument would be an object where key-value pairs provide > > additional details regarding the request. The spec should define a set of > > keys and associated data types which are recognized. There are currently > > two key-value pairs we would like to add: > > > > key: “transactionAmount” > > value: number > > description: For data that is going to be applied towards a > > transaction, the /maximum/ value of the transaction. The browser does not > > guarantee that the returned payment instrument will work, but keeping the > > transaction under this amount will increase the likelihood of receiving a > > valid card number. > > > > key: “transactionCurrency” > > value: string > > description: a valid ISO 4217 currency code that describes the > > currency for transactionAmount. If not provided, the default is “USD”. > > > > Justification? There are upper bounds on certain payment instruments, for > > example different credit cards have different credit limits; a debit card > > is linked to a bank account with a certain balance. It’s a much > preferable > > user experience to be able to catch these problems earlier rather than > > waiting for the merchant to attempt the transaction and have it fail (or > > have a user’s account overdrawn). Concretely, Chromium wants to handle > > transactions over $2000 differently from transactions under that amount. > > > > Does this seem reasonable? > > > > > > -- Evan Stade > > >
Re: [whatwg] Additional details for invoking requestAutocomplete
Perhaps now is a more appropriate time for this discussion, given that requestAutocomplete is now published in the spec (!). -- Evan Stade On Mon, Mar 10, 2014 at 1:33 PM, Evan Stade wrote: > Hi WhatWG. > > Currently, requestAutocomplete lets a user agent provide the same user > experience across multiple sites for common data input flows. A site > describes the data it desires (via a form and autocomplete attributes), and > the user agent uses this information and what it knows about the user to > expedite data input. For example, if one of the form elements has > autocomplete=”cc-number” the browser might provide an experience tailored > for a payment flow, or if there’s an element with autocomplete=”bday” the > browser might use an experience that’s tailored for sharing identiy. > > We’ve found that there are some details of the interaction which might > affect the UX which cannot be inferred from the data inputs. We propose to > add an optional argument to the requestAutocomplete method. Thus invocation > would look like: > > form_element.requestAutocomplete(details); > > This |details| argument would be an object where key-value pairs provide > additional details regarding the request. The spec should define a set of > keys and associated data types which are recognized. There are currently > two key-value pairs we would like to add: > > key: “transactionAmount” > value: number > description: For data that is going to be applied towards a > transaction, the /maximum/ value of the transaction. The browser does not > guarantee that the returned payment instrument will work, but keeping the > transaction under this amount will increase the likelihood of receiving a > valid card number. > > key: “transactionCurrency” > value: string > description: a valid ISO 4217 currency code that describes the > currency for transactionAmount. If not provided, the default is “USD”. > > Justification? There are upper bounds on certain payment instruments, for > example different credit cards have different credit limits; a debit card > is linked to a bank account with a certain balance. It’s a much preferable > user experience to be able to catch these problems earlier rather than > waiting for the merchant to attempt the transaction and have it fail (or > have a user’s account overdrawn). Concretely, Chromium wants to handle > transactions over $2000 differently from transactions under that amount. > > Does this seem reasonable? > > > -- Evan Stade >
[whatwg] Additional details for invoking requestAutocomplete
Hi WhatWG. Currently, requestAutocomplete lets a user agent provide the same user experience across multiple sites for common data input flows. A site describes the data it desires (via a form and autocomplete attributes), and the user agent uses this information and what it knows about the user to expedite data input. For example, if one of the form elements has autocomplete=”cc-number” the browser might provide an experience tailored for a payment flow, or if there’s an element with autocomplete=”bday” the browser might use an experience that’s tailored for sharing identiy. We’ve found that there are some details of the interaction which might affect the UX which cannot be inferred from the data inputs. We propose to add an optional argument to the requestAutocomplete method. Thus invocation would look like: form_element.requestAutocomplete(details); This |details| argument would be an object where key-value pairs provide additional details regarding the request. The spec should define a set of keys and associated data types which are recognized. There are currently two key-value pairs we would like to add: key: “transactionAmount” value: number description: For data that is going to be applied towards a transaction, the /maximum/ value of the transaction. The browser does not guarantee that the returned payment instrument will work, but keeping the transaction under this amount will increase the likelihood of receiving a valid card number. key: “transactionCurrency” value: string description: a valid ISO 4217 currency code that describes the currency for transactionAmount. If not provided, the default is “USD”. Justification? There are upper bounds on certain payment instruments, for example different credit cards have different credit limits; a debit card is linked to a bank account with a certain balance. It’s a much preferable user experience to be able to catch these problems earlier rather than waiting for the merchant to attempt the transaction and have it fail (or have a user’s account overdrawn). Concretely, Chromium wants to handle transactions over $2000 differently from transactions under that amount. Does this seem reasonable? -- Evan Stade
Re: [whatwg] Supporting more address levels in autocomplete
On Tue, Mar 4, 2014 at 4:52 PM, Qebui Nehebkau < qebui.nehebkau+wha...@gmail.com> wrote: > On Tue, Mar 4, 2014 at 11:41 PM, Ian Hickson wrote: > > I think the arguments you've presented so far suggest "address-levelN" > for > > N=1..4, with 4=region and 3=locality, is probably the simplest thing to > > do. I was hoping there might be other people with opinions, to give us > > different perspectives on this, but it seems nobody else cares. :-( > > Since you asked, I think the whole endeavour (of trying to tokenise an > address) is pointless and should be abandoned outright. :) > > Short of my ideal of *only* offering the full address (as used on a > label) as an opaque string, The majority of forms ask for tokenized data; my impression is this is necessary given their backends (be it columns in a user info database, a payment provider that requires tokenized address, etc.) So I don't think it's practical to impose address blob only on the web.
Re: [whatwg] Supporting more address levels in autocomplete
On Tue, Mar 4, 2014 at 4:39 PM, Ian Hickson wrote: > On Tue, 4 Mar 2014, Evan Stade wrote: > > On Tue, Mar 4, 2014 at 3:41 PM, Ian Hickson wrote: > > > > > > > > > > > > > >"address-line1" | > > > > > > >"address-line2" |- "street-address" > > > > > > >"address-line3" | > > > > > > >"address-level4" > > > > > > >"address-level3" > > > > > > >"address-level2" / "locality" > > > > > > >"address-level1" / "region" > > > > > > >"country-name" > > > > > > > > > > This could work. It has the synonym issue (having multiple fields > > > > > that mean the same thing is often the source of confusion). > > > > > > > > > > > > Or we could do: > > > > > > > > > > > > > >"address-line1" | > > > > > > >"address-line2" |- "street-address" > > > > > > >"address-line3" | > > > > > > >"subsublocality" > > > > > > >"sublocality" > > > > > > >"locality" > > > > > > >"region" > > > > > > >"country-name" > > > > > > > > > > This could work. It avoids the synonym problem. > > > > > > > > Yes, this alternative works, but in my opinion is not preferable. > > > > > > Can you elaborate on why this would be worse than the version with > > > synonyms? > > > > Because these words don't really mean anything. From our initial > > proposal: > > > > """ > > Compared to the alternative of adding another one-off such as > > “dependent-locality” or “sub-locality”, we feel this is a more > > descriptive and general way to tackle additional administrative levels > > without making false implications about the semantics of the value > > that is returned. > > """ > > I don't understand how "sublocality" makes any more implications, or has > any less descriptive value, than "address-level3". Can you elaborate on > this? They all seem quite neutral (basically empty of meaning) to me. > "dependent-locality" and "locality" have a fairly precise meaning in the UK. Also in a natural-language conversation, if you ask me what "region" of the country I live in, I'd say "New England", "the Midwest", or some such; certainly not the state where I reside. The descriptions for these tokens are currently pretty specific, for example they say a city would be a locality. But this is not true for Beijing or some other cities. To fix the descriptions, we'd have to change them to something like "region: the highest level administrative region below country in the address" and "locality: the second-highest level administrative region below country in the address", "sub-locality: the third-highest level administrative region [...]". At this point, one wonders why the tokens aren't just [something]1, [something]2, etc. > > > > > > > > >"address-line1" | > > > > > > >"address-line2" |- "street-address" > > > > > > >"address-line3" | > > > > > > >"locality" > > > > > > >"subsubregion" > > > > > > >"subregion" > > > > > > >"region" > > > > > > >"country-name" > > > > > > > > > > This _could_ work, but it seems a bit weirder than > > > > > "subsublocality". > > > > > > > > This would re-define locality, leading to cross-version > > > > incompatibilities. > > > > > > How so? Are people already depending on Chinese addresses' levels 1, > > > 2, and 3 being mapped to region, locality, and nothing respectively? > > > > > > The model with subsubregion does more closely match the specs' current > > > descriptions of 'locality'. > > > > I would argue that nothing in China reliably matches the spec's current > > definition of "locality". That is, in one addr
Re: [whatwg] Supporting more address levels in autocomplete
On Tue, Mar 4, 2014 at 3:41 PM, Ian Hickson wrote: > On Tue, 4 Mar 2014, Evan Stade wrote: > > > > > > I am not convinced it'd be that big a load (users generally know what > > > parts of their addresses are required!). But in any case, if we're > > > talking about mom-and-pop stores with a minimal load of international > > > orders in the first place, it's likely that the customer service load > > > would be pretty minimal. > > > > Then why do so many sites bother to validate data as users input it? > > I don't know. Cargo-cult? Given how poor a job many sites do of this, it's > not clear to me that it's for helping with customer service. In fact, > several times the validating has caused me to have to talk to customer > service to get around their bogus validation. > > > > Country name is always at the end. When I put "street address" above, I > > meant it in the sense of "all the lines of street address". Different > > countries have a different number of lines, but by definition they're > > always all next to each other --- the definition of address-line-N is > > "the Nth line of the street address when it's formatted for display". > > Why do we want street addresses in visual order but region components in > logical order? Is it because in some address schemes the logical > components end up on the same line with punctuation? > > > > > If the layout difference is that great, we should seriously consider > > > documenting that also. > > > > I think it's outside the scope of the autocomplete spec, but there are > > libraries which to do this, such as libaddressinput, which provides a > > service to get formatting data for various coutnries. For example, the > > "fmt" portion of [1] tells you how to format US addresses. Chrome > > integrates libaddressinput into requestAutocomplete so web authors get > > this for free, but they could also use the service on their own if they > > didn't want to rely on requestAutocomplete. > > > > [1] https://i18napis.appspot.com/ssl-address/data/US > > Fair enough. > > > > > > >"address-line1" | > > > > >"address-line2" |- "street-address" > > > > >"address-line3" | > > > > >"address-level4" > > > > >"address-level3" > > > > >"address-level2" / "locality" > > > > >"address-level1" / "region" > > > > >"country-name" > > > > > > This could work. It has the synonym issue (having multiple fields that > > > mean the same thing is often the source of confusion). > > > > > > > > Or we could do: > > > > > > > > > >"address-line1" | > > > > >"address-line2" |- "street-address" > > > > >"address-line3" | > > > > >"subsublocality" > > > > >"sublocality" > > > > >"locality" > > > > >"region" > > > > >"country-name" > > > > > > This could work. It avoids the synonym problem. > > > > Yes, this alternative works, but in my opinion is not preferable. > > Can you elaborate on why this would be worse than the version with > synonyms? > Because these words don't really mean anything. From our initial proposal: """ Compared to the alternative of adding another one-off such as “dependent-locality” or “sub-locality”, we feel this is a more descriptive and general way to tackle additional administrative levels without making false implications about the semantics of the value that is returned. """ > > > > > > >"address-line1" | > > > > >"address-line2" |- "street-address" > > > > >"address-line3" | > > > > >"locality" > > > > >"subsubregion" > > > > >"subregion" > > > > >"region" > > > > >"country-name" > > > > > > This _could_ work, but it seems a bit weirder than "subsublocality". > > > > This would re-define locality, leading to cross-version > > incompatibilities. > > How so? Are people already depending on Chinese addresses' levels 1,
Re: [whatwg] Supporting more address levels in autocomplete
On Tue, Mar 4, 2014 at 12:18 PM, Ian Hickson wrote: > > On Mon, 3 Mar 2014, Evan Stade wrote: > > > > > > > > I don't think you can just write a stack of inputs that accepts > > > > input for any country. The country determines: > > > > > > > > a) what fields make sense > > > > b) what fields are required > > > > c) the order of fields > > > > > > > > You could ignore (a) and settle for a crappy UI that shows all > > > > fields that make sense anywhere in the world, but you'd still be > > > > left with solving (b) and (c). > > > > > > (b) is an easy-to-solve problem: you don't make any of them required, > > > and if the customer entered insufficient fields, they're not getting > > > their package, and will have to be contacted out-of-band. > > > > I don't think the additional load that would place on customer service, > > the number of missing packages, etc., would be considered an "easy" > > problem or even an improvement over whatever they currently have in > > place. > > I am not convinced it'd be that big a load (users generally know what > parts of their addresses are required!). But in any case, if we're talking > about mom-and-pop stores with a minimal load of international orders in > the first place, it's likely that the customer service load would be > pretty minimal. > Then why do so many sites bother to validate data as users input it? > > > > > Can you elaborate on (c)? > > > > US looks like: > > > > Recipient > > Organization > > Street address > > City, State ZIP > > > > Japan looks like: > > > > 〒 ZIP > > State City > > Street address > > Organization > > Recipient > > Ah, interesting. That is indeed a significantly larger difference than I > expected. > > Can you elaborate on these? Where would "address-line2" and > "address-line3" go? Where would "country-name" go? > Country name is always at the end. When I put "street address" above, I meant it in the sense of "all the lines of street address". Different countries have a different number of lines, but by definition they're always all next to each other --- the definition of address-line-N is "the Nth line of the street address when it's formatted for display". > > > If the layout difference is that great, we should seriously consider > documenting that also. > I think it's outside the scope of the autocomplete spec, but there are libraries which to do this, such as libaddressinput, which provides a service to get formatting data for various coutnries. For example, the "fmt" portion of [1] tells you how to format US addresses. Chrome integrates libaddressinput into requestAutocomplete so web authors get this for free, but they could also use the service on their own if they didn't want to rely on requestAutocomplete. [1] https://i18napis.appspot.com/ssl-address/data/US > > > Looking at the suggestions I listed earlier: > > > >"address-line1" | > > >"address-line2" |- "street-address" > > >"address-line3" | > > >"address-line5" > > >"address-line6" > > >"address-line7" / "locality" > > >"address-line8" / "region" > > >"address-line9" / "country-name" > > This presumably wouldn't work sanely for Japanese addresses. > > > > > Or we could do: > > > > > >"address-line1" | > > >"address-line2" |- "street-address" > > >"address-line3" | > > >"subsublocality" > > >"sublocality" > > >"locality" > > >"region" > > >"country-name" > > This could work. It avoids the synonym problem. > Yes, this alternative works, but in my opinion is not preferable. > > > > >"address-line1" | > > >"address-line2" |- "street-address" > > >"address-line3" | > > >"locality" > > >"subsubregion" > > >"subregion" > > >"region" > > >"country-name" > > This _could_ work, but it seems a bit weirder than "subsublocality". > This would re-define locality, leading to cross-version inco
Re: [whatwg] Supporting more address levels in autocomplete
On Mon, Mar 3, 2014 at 2:18 PM, Ian Hickson wrote: > On Mon, 3 Mar 2014, Evan Stade wrote: > > > > I'm still confused. The site author has entered bad markup. Is your > > concern that site authors will be unable to write good markup? > > Some will write good markup, I'm sure. > > Our job as language designers is to maximise the number of authors doing a > good job, and minimise the number of authors who make unintentional > mistakes. > > > > > There's no point us allowing address-level881. It will never be > > > useful. > > > > Is there a point in disallowing it? > > Yeah. It simplifies the language, means there's less to test so it > simplifies testing, it simplifies authoring, it reduces tutorial > complexity, it makes answering questions like "how many should I include" > easy to answer, and so on. > > > > Ultimately it doesn't matter too much, but I would think it's a goal to > > avoid spec churn. > > Adding features isn't such a big deal, especially when they're in response > to changing political conditions. > > > > If we're going to set some limit, let's say 4. > > Ok. > > > > > Well if for some reason you want to exclude non-US customers, sure. > > > But suppose you do want to include all customers, but you're a > > > mom-and-pop store who is just going to put what you put in the form > > > onto the envelope, and who doesn't know the intricacies of each > > > country's postal standards. > > > > > > How many fields should you list? > > > > In this case, address-level-n doesn't help you. In order to be able to > > write an address onto an envelope, you want an address blob, not > > tokenized bits. This address blob was proposed further up the thread, > > and I think it's a good idea, but distinct from the current topic, which > > is how to get tokenized bits for places like China. > > > > Of course, tokenized bits can be used to create an address blob, but it > > requires some sophistication to do so. > > If you take the fields from the spec today and those proposed in this > thread, and concatenate them one-to-a-line in the following order: > >"organization" >"address-line1" >"address-line2" >"address-line3" >"address-level4" >"address-level3" >"address-level2" >"address-level1" >"country-name" >"postal-code" > > ...the mail is going to get where you want it to get, right? > So for the mom-and-pop store, this seems like it would be sufficient. > > Even if they render it as: > >"organization" >"address-line1" >"address-line2" >"address-line3" >"address-level4", "address-level3" "postal-code" >"address-level2" "address-level1" >"country-name" > > ...so that it's optimised for the US, it would still work everywhere, > you'd just have some slightly annoyed postal staff in some countries. > Or some automatic mail-sorting machines which reject your mail completely. I think you have more confidence in the post office than I do. But again, this is something to be addressed separately with a "display-address" token (or whatever you want to call it). > > So I don't think it's right to say that address-level* doesn't help you > in the mom-and-pop store case. It does. > In some sense, you could put all the components of the address in a completely random order and if you're lucky, they'll be unambiguous enough for some human to figure it out. I don't think we should recommend people do that though. > > > > I don't think you can just write a stack of inputs that accepts input > > for any country. The country determines: > > > > a) what fields make sense > > b) what fields are required > > c) the order of fields > > > > You could ignore (a) and settle for a crappy UI that shows all fields > > that make sense anywhere in the world, but you'd still be left with > > solving (b) and (c). > > (b) is an easy-to-solve problem: you don't make any of them required, and > if the customer entered insufficient fields, they're not getting their > package, and will have to be contacted out-of-band. > I don't think the additional load that would place on customer service, the number of missing packages, etc., would be considered an "easy" problem
Re: [whatwg] Supporting more address levels in autocomplete
On Mon, Mar 3, 2014 at 10:28 AM, Ian Hickson wrote: > On Fri, 28 Feb 2014, Evan Stade wrote [slightly edited for correctness]: > > On Fri, Feb 28, 2014 at 5:47 PM, Ian Hickson wrote > > [slightly edited for correctness]: > > > > > > My concern is that authors do something like this: > > > > > > > > > > > > > > > > > > ...and then the user enters their address: > > > > > >1600 Amphitheatre Parkway > > >Mountain View > > >CA > > > > > > ...and then the user goes to another site: > > > > > > > > > > > > > > > > > > > > > > > > ...and the browser autofills: > > > > > >1600 Amphitheatre Parkway > > >(empty) > > >Mountain View > > >Mountain View > > >CA > > > > > > ...or some such. > > > > So the user is tricked into entering wrong data? > > No, the user enters correct data, and the site uses it fine. The problem > is just that the site author got the autocomplete="" field names wrong. > > > > (i.e. CA for address-level3 instead of address-level1) A web author > > could just as easily cause the user to enter wrong data to be stored by > > doing: > > > > > > This is a concern, but far less of one, IMHO, since there's a dedicated > "postal-code" field. > I'm still confused. The site author has entered bad markup. Is your concern that site authors will be unable to write good markup? Is there a name for these fields that you think would be less confusing to the authors? > > > > > > > How does a site know how many levels to offer? > > > > > > > > It offers as many as it knows what to do with. It probably wouldn't > > > > know what to do with n=5, or n=100, and it's highly unlikely a user > > > > agent would return a value for those levels anyway, so practically > > > > speaking, n=1 to n=3 should be sufficient for now (although n=4 > > > > seems possible in the near future). But I don't see the purpose in > > > > setting a limit in the spec. > > > > > > This makes me extremely uncomfortable. > > > > > > We're saying, "we don't know how to do this, I hope you do". Why would > > > we be less able to answer this than Web authors? It's not like Web > > > authors are experts in postal addresses. > > > > > > I think we should pick the number that is actually needed, and be firm > > > that that is the number. > > > > That's not how I would interpret it. We do know how many levels we > > currently support. > > How many? Let's put that number in the spec. > > > We don't know how many levels we might support in the future. The number > > depends on political forces. > > Sure. We can always change the spec when we change the implementations. > There's no point us allowing address-level881. It will never be useful. > Is there a point in disallowing it? Ultimately it doesn't matter too much, but I would think it's a goal to avoid spec churn. If we're going to set some limit, let's say 4. > > > > > > > What should a Chinese user interacting with a US company put in as > > > > > their address, if they want something shipped to China? > > > > > > > > They would put in the same address regardless of the nationality of > > > > the company, assuming the company is able to properly handle their > > > > address. > > > > > > Shouldn't we want everyone to be able to handle everyone's address? > > > > I think I've misunderstood your original question because I don't know > > how my answer indicates someone would not be able to handle someone's > > address. But to answer the new question, no: if I am only willing to > > ship to US addresses, why do I need to be able to handle a Chinese > > address? > > Well if for some reason you want to exclude non-US customers, sure. But > suppose you do want to include all customers, but you're a mom-and-pop > store who is just going to put what you put in the form onto the envelope, > and who doesn't know the intricacies of each country's postal standards. > > How many fields should you list? > In this case, address-level-n doesn't help you. In order to be able to write an address onto an envelope, you want an address blob, not t
Re: [whatwg] Supporting more address levels in autocomplete
On Fri, Feb 28, 2014 at 5:47 PM, Ian Hickson wrote: > On Mon, 24 Feb 2014, Jukka K. Korpela wrote: > > 2014-02-22 3:03, Ian Hickson wrote: > > > > > > (Note that a lot of people in the UK have no idea how to write their > > > address according to current standards. For example, people often > > > include the county, give the "real" town rather than the "post town", > > > put things out of order, indent each line of the address, etc.) > > > > The phenomenon is probably not limited to the UK. Few people even know > > the current standards (national and international). > > Well sure, but since we're writing a standard, if our assumption is that > people don't know standards, we're not going to reach a useful conclusion. > > > > Some fine-grained control for naming different components of an address > > are undoubtedly useful at times. It would be even more useful to have a > > common, "standard" name for just an address. That is, whatever someone > > wants the sender to put in an envelope. Its internal structure does not > > matter, as long as it works, and as usual, it is up to the recipient to > > specify the address in a manner that works. > > > > Forms that require the user to split his address to small pieces may > > have their reasons. But if you just want to have an address to send > > stuff to, then all you need is a working postal address. A textarea > > with, say, name="postal", if used on different pages, would then let the > > user enter his entire address very simply, after just once typing it. > > > > Probably "postal" should be specified so that it relates to a postal > > address that is complete for delivery except the recipient name. The > > reason is that the name is so often asked separately > > On Mon, 24 Feb 2014, Evan Stade wrote: > > > > I agree with this, and plan to propose it separately from the proposal > > currently under discussion. It might be hard to parse a working address > > out of a free-form input, but the other direction is doable enough: > > creating a block of text suitable to printing on an envelope given > > tokenized values. This tackles the problem of how to format an > > autocompleted address for a particular country and UI language (i.e. in > > the user agent has to know how to do it, but the website doesn't). > > We can definitely add something like this. We already have a simpler > version of this for street addresses. > > > On Mon, 24 Feb 2014, Charles McCathie Nevile wrote: > > > > That depends on whether you want to force your customers to think like > > the Post Office, or whether you prefer to be responsive to your > > customers. Speaking without data, I suspect that nervousness at not > > being able to put *what someone thinks* is their address translates > > fairly readily into a certain amount of failure to proceed with a > > transaction. > > I'd love to see real data on this. I can imagine scenarios that would lead > this to go both ways. > > > On Mon, 24 Feb 2014, Dan Brickley wrote: > >> > > Who is using the data? Just post offices? Or taxi drivers, pizza > > delivery bikers, pedestrians? > > The latter three are unlikely to really need much more depth at the > locality level. > > > On Mon, 24 Feb 2014, Evan Stade wrote: > > > > Regarding UK addresses, libaddressinput[1], which is used by Google for > > various products, currently accepts two levels of administrative region > > for GB: city and optional county. > > You need two levels, but those aren't it. :-) Counties haven't officially > been used in UK addresses since the mid 90s. > > > > > This would be the first open-ended field name. Do we really want to > > > make this open-ended? What happens if a form has n=1..3, and another > > > has n=2..4? What if one has n=1, n=2, and n=4, but not n=3? > > > > I don't know why a web author would do this > > Web authors do all kinds of crazy stuff. We have to be ready for it such > that we never end up forced to introduce weird heuristics. > > > > but n=m doesn't require n=m-1 or n=m+1 to be present. n=2..4 would just > > mean the site didn't get the n=1 value. > > My concern is that authors do something like this: > > > > > > ...and then the user enters their address: > >1600 Amphitheatre Parkway >Mountain View >CA > > ...and then the user goes to another site: > > > > > > > > ...and the browser
Re: [whatwg] Supporting more address levels in autocomplete
(Trying again from alternate email address; apologies if this message shows up twice.) Regarding UK addresses, libaddressinput[1], which is used by Google for various products, currently accepts two levels of administrative region for GB: city and optional county. > This would be the first open-ended field name. Do we really want to make > this open-ended? What happens if a form has n=1..3, and another has > n=2..4? What if one has n=1, n=2, and n=4, but not n=3? I don't know why a web author would do this, but n=m doesn't require n=m-1 or n=m+1 to be present. n=2..4 would just mean the site didn't get the n=1 value. > How does a site know how many levels to offer? It offers as many as it knows what to do with. It probably wouldn't know what to do with n=5, or n=100, and it's highly unlikely a user agent would return a value for those levels anyway, so practically speaking, n=1 to n=3 should be sufficient for now (although n=4 seems possible in the near future). But I don't see the purpose in setting a limit in the spec. > What should a Chinese user interacting with a US company put in as their > address, if they want something shipped to China? They would put in the same address regardless of the nationality of the company, assuming the company is able to properly handle their address. Which inputs are visible to the user should depend on which country they're entering. This means that if a user changes the country, the inputs shuffle around and hide or show. (requestAutocomplete places the onus of understanding all this on the user agent, but there are javascript implementations out there.) > So they would be synonyms? Or separate fields? They are pseudo-synonyms. In the US, "region" aligns with "address-level-1", and either one would return the same value. In the UAE, where there are cities but no higher level administrative region, "locality" aligns with "address-level-1". In China, "address-level-1" is a province a province-level city such as Beijing. Beijing is also "region", confusingly, and a district of the city is a "locality". So generally speaking, if I ship to both China and the US, I would create a form with "address-level-[1..4]" and if the user starts to enter a US address, only show the first 2 levels. If the user starts to enter a Chinese address, show more levels. If using requestAutocomplete, all the inputs are hidden all the time anyway. If I am making a site that ships to just the US, I'd probably go with the more intuitive "region" and "locality" and ignore address-level-n. > Forms that require the user to split his address to small pieces may > have their reasons. But if you just want to have an address to send > stuff to, then all you need is a working postal address. A textarea > with, say, name="postal", if used on different pages, would then let the > user enter his entire address very simply, after just once typing it. I agree with this, and plan to propose it separately from the proposal currently under discussion. It might be hard to parse a working address out of a free-form input, but the other direction is doable enough: creating a block of text suitable to printing on an envelope given tokenized values. This tackles the problem of how to format an autocompleted address for a particular country and UI language (i.e. in the user agent has to know how to do it, but the website doesn't). -- Evan Stade [1] https://code.google.com/p/libaddressinput/
