[whatwg] new autocomplete="" values for authentication forms (was Re: Autocomplete and autofill features and feedback thereon)
Jake Archibald
jaffathecake at gmail.com
Thu Mar 6 23:54:36 PST 2014
I like this, also provides hooks for something like
form.requestAutocomplete to do one-click account creation, along with
password generation.
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.
>
> Thoughts?
>
>
> Ted
>
More information about the whatwg
mailing list