Re: [whatwg] Various autocomplete= topics
On Mon, May 5, 2014 at 10:38 PM, Matthew Noorenberghe mattn+wha...@mozilla.com wrote: On Fri, Apr 11, 2014 at 3:36 PM, Edward O'Connor eocon...@apple.com wrote: I actually have a similar problem with purely JS-handled forms even unrelated to credentials. Because the form is never really submitted (even if we reuse the submit infrastructure, we cancel the 'submit' event and handle the work on the JS side), there's never an indication to the UA that it should save the fields, and so autofill never works right on these forms, even for things like postal addresses or e-mail addresses. In Firefox, we save the form values after validation but before the submit event is dispatched to content. This way we successfully save the form fields in form history when a script is handling the actual submission. This also helps against sites who try to manipulate the form fields upon submission to avoid having them saved (see https://bugzilla.mozilla.org/show_bug.cgi?id=257781 ). We've been doing this for a long time and I don't recall any complaints as long as I've been working on password and form manager for Firefox (since 2009). There are many websites that use click handlers on buttons outside forms instead of using form submission and those fields don't get saved in Firefox. I suspect web developers don't realize that they are losing out on form history and other benefits like being able to submit the form with the Enter key from a text input. I don't see sites that are not having their fields saved by not using form submission switching to calling a new API when they can instead use an onsubmit handler which has other benefits. Given that Firefox already saves values with preventDefault inside form submit handlers and click handlers on submit buttons, and the other benefits of sites using form submission, I don't think a new API is needed. The problem right now is that there are two legitimate reasons that a site may return false from the submit handler, either because the submission failed validation in some way or because submission is being handled via script. Browsers can either ignore this distinction (e.g. Firefox) or try and separate the two heuristically (e.g. Chrome). Both are reasonable approaches given the current state of the world, but neither are ideal. We should allow sites to make this distinction. I agree that we shouldn't necessarily add contortions for sites that don't use form submission, but currently there isn't a right way to do this even if the site wants to. For the pure JS case, an API (probably on the form itself) would make sense and seems relatively easy. I've filed a bug on this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25238 This case is pretty weird. Authors are going out of their way to avoid using the built in platform features that would get them autofill saving for free. In some cases, they might be doing this precisely because they want to prevent autofill but can't count on autocomplete=off anymore. It seems like more evangelism is needed to let authors know that preventDefault inside a form submission handler is the better way to handle forms where navigation isn't wanted. The benefits are: form history, password management, better UX (allowing submission via Enter when inputs are in a form), and possibly better accessibility(?). I've been thinking about cases where we could detect the pattern of fake forms (using text inputs and buttons with click handlers together without a form) and provide notices in developer tools to help evangelize but it's looking to be tricky. -- Matthew Noorenberghe
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 est...@chromium.org 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
On Fri, Apr 11, 2014 at 3:36 PM, Edward O'Connor eocon...@apple.com wrote: I actually have a similar problem with purely JS-handled forms even unrelated to credentials. Because the form is never really submitted (even if we reuse the submit infrastructure, we cancel the 'submit' event and handle the work on the JS side), there's never an indication to the UA that it should save the fields, and so autofill never works right on these forms, even for things like postal addresses or e-mail addresses. In Firefox, we save the form values after validation but before the submit event is dispatched to content. This way we successfully save the form fields in form history when a script is handling the actual submission. This also helps against sites who try to manipulate the form fields upon submission to avoid having them saved (see https://bugzilla.mozilla.org/show_bug.cgi?id=257781 ). We've been doing this for a long time and I don't recall any complaints as long as I've been working on password and form manager for Firefox (since 2009). There are many websites that use click handlers on buttons outside forms instead of using form submission and those fields don't get saved in Firefox. I suspect web developers don't realize that they are losing out on form history and other benefits like being able to submit the form with the Enter key from a text input. I don't see sites that are not having their fields saved by not using form submission switching to calling a new API when they can instead use an onsubmit handler which has other benefits. Given that Firefox already saves values with preventDefault inside form submit handlers and click handlers on submit buttons, and the other benefits of sites using form submission, I don't think a new API is needed. For the pure JS case, an API (probably on the form itself) would make sense and seems relatively easy. I've filed a bug on this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25238 This case is pretty weird. Authors are going out of their way to avoid using the built in platform features that would get them autofill saving for free. In some cases, they might be doing this precisely because they want to prevent autofill but can't count on autocomplete=off anymore. It seems like more evangelism is needed to let authors know that preventDefault inside a form submission handler is the better way to handle forms where navigation isn't wanted. The benefits are: form history, password management, better UX (allowing submission via Enter when inputs are in a form), and possibly better accessibility(?). I've been thinking about cases where we could detect the pattern of fake forms (using text inputs and buttons with click handlers together without a form) and provide notices in developer tools to help evangelize but it's looking to be tricky. -- Matthew Noorenberghe
Re: [whatwg] Various autocomplete= topics
On Fri, Apr 25, 2014 at 4:54 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 3 Apr 2014, Mike West wrote: On Wed, Apr 2, 2014 at 10:56 PM, Ian Hickson i...@hixie.ch wrote: Also, consider the case of login forms without username fields. You see this sort of thing a lot these days, when sites remember who was last logged in: form labelPassword for hober: input type=password name=pw/label pNot hober? a href=...Click here to sign in/a. /form It's difficult for tools to manage the user's auth info for such pages. How can tools discover what the username is? The obvious solution, in a world with autocomplete=username, would be to add input type=hidden autocomplete=username name=username value=hober to the form. So far, autocomplete= hasn't applied to input type=hidden. This would be a bit weird, giving it a different meaning than usual (providing information to the UA, rather than getting information from the UA). I'm a bit skeptical of this kind of overloading. Not sure what the right solution is, though. As Garrett noted, this is already a solution Google is using, though not with explicit syntax, just taking advantage of existing heuristics. Paving this (potential) cowpath isn't really that weird. That said, an alternative might be to add a mechanism of associating autocompletion metadata with the field in order to give the UA enough context to fill it in. For example, if a password is being requested for a known username, that username could be added as an new autocomplete-username attribute (similar to the 'data-*' construct HTML already supports): input type=password autocomplete-username=hober On Fri, 11 Apr 2014, Edward O'Connor wrote: It is kind of weird. Given that, maybe this case should have new syntax. I'm OK with overloading autocomplete=username or with new syntax. I'm not sure I really understand how autocomplete-* would work (e.g. would you have to specify it for all three fields of a change-password form?). Having autocomplete= mean something slightly different on type=hidden does make some sense, even if it is overloading. It has the advantage of fitting into the current syntax machinery, too. I've made a proposal in this bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25471 I would be particularly interested in feedback from vendors who haven't commented on this yet. Will this overloading work for you? On Fri, 11 Apr 2014, Edward O'Connor wrote: I actually have a similar problem with purely JS-handled forms even unrelated to credentials. Because the form is never really submitted (even if we reuse the submit infrastructure, we cancel the 'submit' event and handle the work on the JS side), there's never an indication to the UA that it should save the fields, and so autofill never works right on these forms, even for things like postal addresses or e-mail addresses. For the pure JS case, an API (probably on the form itself) would make sense and seems relatively easy. I've filed a bug on this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25238 This case is pretty weird. Authors are going out of their way to avoid using the built in platform features that would get them autofill saving for free. In some cases, they might be doing this precisely because they want to prevent autofill but can't count on autocomplete=off anymore. I'm not sure what you mean here. The context is a form that is used in a purely scripted fashion. It's not at all obvious how to tell the user agent to save the data in this situation. I don't think authors are going out of their way to avoid using built-in platform features; what feature should they use here? On Fri, 11 Apr 2014, Edward O'Connor wrote: For the real submission case, I guess what we want is a way to say autocomplete=off after the fact, basically. An HTTP header seems like the most obvious solution. https://www.w3.org/Bugs/Public/show_bug.cgi?id=25239 Again, these need multiple vendors on board to make progress. Browsers 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
Re: [whatwg] Various autocomplete= topics
For the real submission case, I guess what we want is a way to say autocomplete=off after the fact, basically. An HTTP header seems like the most obvious solution. https://www.w3.org/Bugs/Public/show_bug.cgi?id=25239 Again, these need multiple vendors on board to make progress. Browsers are moving away from respecting autocomplete=off. I don't think we should be adding a new but basically equivalent mechanism. 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 actually have a similar problem with purely JS-handled forms even unrelated to credentials. Because the form is never really submitted (even if we reuse the submit infrastructure, we cancel the 'submit' event and handle the work on the JS side), there's never an indication to the UA that it should save the fields, and so autofill never works right on these forms, even for things like postal addresses or e-mail addresses. For the pure JS case, an API (probably on the form itself) would make sense and seems relatively easy. I've filed a bug on this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25238 This case is pretty weird. Authors are going out of their way to avoid using the built in platform features that would get them autofill saving for free. In some cases, they might be doing this precisely because they want to prevent autofill but can't count on autocomplete=off anymore. In most of the cases that I've seen where this comes up (e.g. Pandora) it seems like the entire site does navigation via AJAX + history.pushState(). It doesn't seem like the site is trying to avoid password managers so much as they are trying to keep the aesthetic of their site consistent. The requestAutocomplete() API is a Chrome proprietary feature right now so it's sort of acadmic, but: 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. Agreed. I don't see the benefit of requestAutocomplete() here. Ted
Re: [whatwg] Various autocomplete= topics
Hi, Ian wrote: Is there any reason to have two fields here, why not just new both times? That works for me. Browsers can supply the same value for multiple autocomplete=new-password fields in the same form. Also, should we have an old field for the old password, or is the lack of an autofill field sufficient? I think it makes sense to have an old/current password token, for change password forms. It also helps to distinguish sign up forms from sign in forms, as Mike mentioned in the bug. I've filed a bug to track this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25236 It needs multiple vendors on board to make progress. […] I've filed a bug to track this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25237 It needs multiple vendors on board to make progress. Chrome has also expressed interest on both of these bugs. Also, consider the case of login forms without username fields. You see this sort of thing a lot these days, when sites remember who was last logged in: form labelPassword for hober: input type=password name=pw/label pNot hober? a href=...Click here to sign in/a. /form It's difficult for tools to manage the user's auth info for such pages. How can tools discover what the username is? The obvious solution, in a world with autocomplete=username, would be to add input type=hidden autocomplete=username name=username value=hober to the form. So far, autocomplete= hasn't applied to input type=hidden. This would be a bit weird, giving it a different meaning than usual (providing information to the UA, rather than getting information from the UA). I'm a bit skeptical of this kind of overloading. It is kind of weird. Given that, maybe this case should have new syntax. I'm OK with overloading autocomplete=username or with new syntax. I don't have a particular color to suggest for the bikeshed. For the real submission case, I guess what we want is a way to say autocomplete=off after the fact, basically. An HTTP header seems like the most obvious solution. https://www.w3.org/Bugs/Public/show_bug.cgi?id=25239 Again, these need multiple vendors on board to make progress. Browsers are moving away from respecting autocomplete=off. I don't think we should be adding a new but basically equivalent mechanism. I actually have a similar problem with purely JS-handled forms even unrelated to credentials. Because the form is never really submitted (even if we reuse the submit infrastructure, we cancel the 'submit' event and handle the work on the JS side), there's never an indication to the UA that it should save the fields, and so autofill never works right on these forms, even for things like postal addresses or e-mail addresses. For the pure JS case, an API (probably on the form itself) would make sense and seems relatively easy. I've filed a bug on this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25238 This case is pretty weird. Authors are going out of their way to avoid using the built in platform features that would get them autofill saving for free. In some cases, they might be doing this precisely because they want to prevent autofill but can't count on autocomplete=off anymore. The requestAutocomplete() API is a Chrome proprietary feature right now so it's sort of acadmic, but: 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. Agreed. I don't see the benefit of requestAutocomplete() here. Ted
Re: [whatwg] Various autocomplete= topics
On Wed, Apr 2, 2014 at 10:56 PM, Ian Hickson i...@hixie.ch wrote: Also, consider the case of login forms without username fields. You see this sort of thing a lot these days, when sites remember who was last logged in: form labelPassword for hober: input type=password name=pw/label pNot hober? a href=...Click here to sign in/a. /form It's difficult for tools to manage the user's auth info for such pages. How can tools discover what the username is? The obvious solution, in a world with autocomplete=username, would be to add input type=hidden autocomplete=username name=username value=hober to the form. So far, autocomplete= hasn't applied to input type=hidden. This would be a bit weird, giving it a different meaning than usual (providing information to the UA, rather than getting information from the UA). I'm a bit skeptical of this kind of overloading. Not sure what the right solution is, though. As Garrett noted, this is already a solution Google is using, though not with explicit syntax, just taking advantage of existing heuristics. Paving this (potential) cowpath isn't really that weird. That said, an alternative might be to add a mechanism of associating autocompletion metadata with the field in order to give the UA enough context to fill it in. For example, if a password is being requested for a known username, that username could be added as an new autocomplete-username attribute (similar to the 'data-*' construct HTML already supports): input type=password autocomplete-username=hober -mike -- Mike West mk...@google.com Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Re: [whatwg] Various autocomplete= topics
[General point, so not quoting anyone in particular] [Resending to list, apologies to Ian] Why would you define any address components other than those in vCard, a standard with massive implementation and interoperable with most address book applications and services? -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
