[whatwg] RFC: <input type="username">
Ian Hickson
ian at hixie.ch
Mon Aug 2 18:12:37 PDT 2010
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?
> [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?
> 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.
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.
On Thu, 6 May 2010, Markus Ernst wrote:
>
> Maybe it is a problem to have several functionalities mixed up in the
> type attribute, such as control display, autofill and validation
> functionalities. OTOH there are validation hints both in the type and
> pattern attributes.
>
> Maybe keywords could be added as possible values of the pattern
> attribute, in order to provide standard validation types such as e-mail,
> numeric, or maybe also date and datetime.
>
> <input type="text" pattern="email">
> <input type="username" pattern="email">
This only seems to be a problem if we overload type="" for two different
axes (the type of data, in this case an e-mail address, and the intent of
the data, in this case a username).
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg
mailing list