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

Received on Friday, 11 April 2014 22:37:09 UTC