[whatwg] RFC: <input type="username">

[Dirk Pranke]

On Mon, Aug 2, 2010 at 6:12 PM, Ian Hickson <ian at hixie.ch> wrote:
>
> This thread primarily discussed ways to allow users to log in and out of
> sites, possibly through improvements to the forms model.
>
> This is an area that seems to be under a lot of active research, so it's
> probably premature to change the HTML spec at this point. I haven't
> introduced any new form types.
>
> Some comments on a few of the specific points raised:
>
> On Tue, 4 May 2010, Eitan Adler wrote:
>>
>> Use cases:
>> 1) A screen reader that sees a form with a type=username and a
>> password field. The screen reader could just ask "Log in to this site?
>> [y/n]?". No further context would be needed.
>
> My browsers already do this on many of my sites; why can't an AT?
>
>
>> 2) UAs can more easily discover login forms and offer things such as
>> Firefox's Account Manager [1] or a "remember me" feature
>
> There are a variety of ways this can be done today (e.g. the name="",
> id="", or class="" attributes; declarative descriptions as used by [1]; a
> <link rel> pointing to a form control; microformats; etc); a new input
> field type doesn't seem necessary to do this.
>
>
>> 3) Currently autofill for usernames looks for something like
>> id="username" or name="username". However on certain websites this
>> fails. Furthermore some websites offer a "find other members" feature
>> where you could type in a username. I've often seen these fields filled
>> in automatically with my name.
>
> Why would sites where this doesn't work today use a new feature to do
> this? Surely they can do this now already, so why aren't they doing it?
>

I suspect that this is usually a result of ignorance. I don't think
many content authors are aware of how form-fillers work.

>
>> [1] http://www.mozilla.com/en-US/firefox/accountmanager/
>
> On Tue, 4 May 2010, Steve Dennis wrote:
>> On 4/05/2010, at 9:07 AM, timeless wrote:
>> >
>> > Why would a site which doesn't cooperate with today's autofill
>> > features choose to cooperate with your proposal?
>>
>> Because id="username" isn't a standard as such.  Having it specified in
>> a spec is likely to help people adopt it more quickly.
>
> RFC3106 has specified this since 2001, and has been implemented for a long
> time: https://tools.ietf.org/html/rfc3106
>
> It didn't seem to do much to make adoption happen more quickly.
>
> Why would this new idea make things go faster?
>

I'm not sure what you mean by "has been implemented for a long time".
I am not aware of any ecommerce site of any significant size
implementing this standard. Having been responsible for one such site
from roughly 2002-2008, I had never heard of this spec, nor have
several people that I would expect to have heard of it if it had ever
achieved any traction at all. This makes me suspect that this is not a
great example to hold up.

I think it is pretty well known that simply getting a document
published and declaring it a standard is not sufficient to ensuring
adoption, but not having a document published is certainly a deterrent
to adoption.

>
>> Saying "why bother?" about all the broken sites on the web totally
>> defeats the purpose of what everyone here's trying to achieve.
>
> Sure, but we can't help these sites without their cooperation. How do we
> get them to cooperate? We've tried standards (RFC3106), we've tried making
> the user experience better (password fillers). What else can we try?
> Another <input> doesn't seem to address this.
>

In the absence of any recommended convention that people are actually
aware of, sites will continue to make life difficult for password
managers and form-fillers. Encouraging people to follow a convention
would be a good thing, even if we have a large legacy problem that
would have to be addressed through other things.

Suggesting that people follow 3106 instead of creating a new input
type (which is I think what you're doing) is certainly one possible
solution here.

>
> On Tue, 4 May 2010, Dirk Pranke wrote:
>>
>> I think this idea is halfway to what I'd want to see. Namely, we should
>> add an <input type="login"> field that triggers a powerbox/dialog (much
>> like the <input type="file"> dialog) that can collect whatever sort of
>> credentials are needed (username / password, two-factor auth, FB connect
>> credentials, OpenID/OAuth credentials, etc.). I agree that it should
>> probably build on top of the Account Manager spec.
>>
>> I think the whole login process needs to be taken as out of page as
>> possible. Unfortunately, the auto-login mechanism in Mozilla's prototype
>> is probably too out of page, and so there should be a way to trigger the
>> login from an in-page element (hence the above).
>
> I strongly urge people to experiment in this area. This is the kind of
> thing that should precede standardisation.
>

Agreed; I think there is a lot of value in having a conversation about
how we might improve login flows on this list, but it is too early to
think that we can standardize on one particular implementation.
Perhaps the WHATWG needs an experimental track in addition to a
standards track?

-- Dirk