W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2010

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

From: Dirk Pranke <dpranke@chromium.org>
Date: Tue, 4 May 2010 18:27:18 -0700
Message-ID: <t2o3726d1bf1005041827s955234c9pa9e3786b46968266@mail.gmail.com>
On Tue, May 4, 2010 at 2:02 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> On Tue, May 4, 2010 at 1:53 PM, Dirk Pranke <dpranke at chromium.org> wrote:
>> On Tue, May 4, 2010 at 12:08 AM, Eitan Adler <eitanadlerlist at gmail.com> 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.
>>> 2) UAs can more easily discover login forms and offer things such as
>>> Firefox's Account Manager [1] or a "remember me" feature
>>> 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.
>>> 4) I'm sure there are others....
>>>
>>> The proposal:
>>> A type="username" is added to the input element. type="username" would
>>> MUST only be used for the name that is used to log in to the site. It
>>> MUST NOT be used for registration forms or anything else that requires
>>> a username. A form MAY have up to one (but not more) type="username"
>>> input field.
>>>
>>> [1] http://www.mozilla.com/en-US/firefox/accountmanager/
>>>
>>
>> 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).
>
> For what it's worth, I'm not terribly interested in adding more to the
> patchwork that is the online login experience that is today. I'm much
> more interested in something like this:
>
> http://hacks.mozilla.org/2010/04/account-manager-coming-to-firefox/
>

I did note that my proposal should build on top of the account manager
protocol referred to by that link.

The principal difference or change is that as far as I know, Mozilla's
account manager offers only an out-of-page experience for managing
your logged-in status. It remains to be seen how successful this would
be (will users even notice something that is only in the browser
chrome? Do they have to learn what the login mechanism is on every
different type of browser they use?, etc. Are site owners going to be
willing to give up that much control over the sign-in/sign-out
experience?). I am suggesting an in-page option that supplements
(complements?) the in-chrome, so that site owners that want to can
continue to promote sign-in/sign-out through in-page elements can do
so in a way that uses the same infrastructure and provides a more
secure and coherent experience across sites at the same time.

-- Dirk
Received on Tuesday, 4 May 2010 18:27:18 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:23 UTC