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

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@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@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@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
>> >
>>
>
>

Received on Friday, 28 March 2014 20:58:38 UTC