[whatwg] new autocomplete="" values for authentication forms (was Re: Autocomplete and autofill features and feedback thereon)

[Garrett Casto]

Any comments on this? I'm not sure where this fits in Safari's timeline,
but it's reasonably high up on Chrome's priority list.


On Fri, Mar 7, 2014 at 4:34 PM, Garrett Casto <gcasto at chromium.org> wrote:

> I've been meaning to suggest this for a while now, but just haven't gotten
> around to it. Chrome would be definitely implement autofill attributes
> along these lines. I'm relatively indifferent to the exact syntax.
>
> Another related issue that would be nice to address would be allowing
> sites to positively assert that authentication succeeded. For sites that
> authenticate client side via XHR, standardizing something like
> window.external.AutoCompleteSaveForm() would be very helpful. For sites
> that validate server side, I'm less sure what the correct avenue to convey
> this information would be (response code, header, ...). I'm assuming that
> this will be more contentious than adding username and password attribution
> and I don't want to hold that up, but I would like to see opinions on this.
>
>
> On Thu, Mar 6, 2014 at 11:54 PM, Jake Archibald <jaffathecake at gmail.com>wrote:
>
>> I like this, also provides hooks for something like
>> form.requestAutocomplete to do one-click account creation, along with
>> password generation.
>>
>
> Eventually doing something like requestAutocomplete for account creation
> would be nice, but there are other issues that we would need to solve
> first. For instance, most signup flows include a CAPTCHA and options to
> e.g. receive email.
>
>
>> On 5 Mar 2014 20:39, "Edward O'Connor" <eoconnor at apple.com> wrote:
>>
>> > Hi,
>> >
>> > Ian wrote, in 2012:
>> >
>> > >> This might fall under the broader class of "identity"-related fields,
>> > >> which I think merit their own carefully thought out set of tokens.
>> > >> There was some work done on the beginnings of such a specification --
>> > >> see https://wiki.mozilla.org/Identity-inputs -- but my current
>> > >> understanding is that this is an area in need of further development.
>> > >
>> > > I'm happy to add more things like this to the spec, but I don't know
>> > > what to add exactly. If there is a concrete description of what fields
>> > > I should add here, I'd be happy to do so.
>> >
>> > The techniques browsers use for autofilling auth information would
>> > benefit enormously from some additional autocomplete="" values. The wiki
>> > page Ilya mentioned captures the use cases pretty well. I think these
>> > are the critical ones that capture the most common cases:
>> >
>> > # Passwords
>> >
>> > On "change your password" forms, which <input type=password> is your
>> > current password? Which is the new password? Browsers want to avoid
>> > filling the old password into the new or confirm password fields.
>> > Additionally, distinguishing such fields would help tools that generate
>> > passwords. These are useful on both sign-up and change password forms.
>> >
>> > <input type=password>                      - your current password
>> > <input type=password autocomplete=new>     - a new password
>> > <input type=password autocomplete=confirm> - the new password, again
>> >
>> > Next to the other autocomplete values, "new" and "confirm" don't look
>> > descriptive enough. "new-password" and "confirm-password", maybe?
>> > "<input type=password autocomplete=new-password>" feels redundant and
>> > verbose to me.
>> >
>> > # Usernames
>> >
>> > Lots of websites use email addresses as usernames. Tools should be able
>> > to distinguish email-used-as-username fields from other email fields.
>> > This can also help on "forgot password"/"forgot username" forms.
>> >
>> > <inpyt type=text autocomplete=username>  - your username on this site
>> > <input type=email>                       - your preferred email address
>> > <inpyt type=email autocomplete=username> - your username on this site,
>> >                                            not your preferred email
>> >                                            address
>> > <input type=url autocomplete=username>   - OpenID
>> >
>> > 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>
>> > <label>Password for hober: <input type=password name=pw></label>
>> > <p>Not 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.
>> >
>>
>
> The Google login pages recently changed to work like this. To continue
> working with Chrome, we had them add a <input type=text value=username
> class=hidden> field. I agree that it would be better if you could just use
> type=hidden instead of having to manually hide the field though.
>
>
>> > Thoughts?
>> >
>> >
>> > Ted
>> >
>>
>
>