Re: [whatwg] RFC: input type=username
On Mon, 2 Aug 2010, Dirk Pranke wrote: On Mon, Aug 2, 2010 at 6:12 PM, Ian Hickson i...@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: [...] 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. That's possible. The solution then is to provide more documentation on this, rather than add more features that would continue to not be well understood. 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 mean some browsers have supported it. 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. I think we should at least try that first, given the potential cost of creating new features. Perhaps the WHATWG needs an experimental track in addition to a standards track? That's what browsers and extensions like Gears are. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] RFC: input type=username
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. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] RFC: input type=username
On Mon, Aug 2, 2010 at 6:12 PM, Ian Hickson i...@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
Re: [whatwg] RFC: input type=username
I think using the role attribute is the best solution here: input type=text role=username input type=email role=username This way we're using the type attribute to indicate what sort of data is being entered, and the role attribute to indicate how it will be used. I think the separation of these is sensible, although it's not entirely consistent across the spec (in my model, search would be a role on a type=text). It's also backwards compatible with HTML4 and with current implementations of HTML5, and could tie in with the rest of ARIA's roles model. The same concept could, for instance, also be applied to a signup form where there is a check box for opting in to marketing: input type=checkbox role=optin You'd need to use a role attribute of login or signup on the form as well to give context to things like role=username so the browser would know what behaviour is appropriate. As someone pointed out, the form element isn't always available if you're working with ASP.NET, so it would seem right to make the roles legal for fieldset, section and div as well. In fact, it would seem right anyway because you could have something like an ecommerce site where there's a single form to place an order which deals with payment for the current order as well as signup for the account. David Goss
Re: [whatwg] RFC: input type=username
The way I see it is that instead of browsers traversing the DOM looking for an input field of either id=username or name=username or even class=username, they now only have to look for an input of type username. Makes it a lot easier for both developers and browser vendors as they now only have to look for an input of type username and gives developers the freedom to use any name, id or class. But in many cases the username is an e-mail address, then you get a conflict with type=email. type=email is expected to (depending on the browser) allow you to search into/autocomplete from your address book. I really don't see a conflict here, it's not about syntax, it's about semantics (otherwise, just use a pattern= constraint). The input type='email' isn't only about semantic. The browser has to check if the email is valid according to HTML5 specifications. Please, have a look at: http://dev.w3.org/html5/spec/forms.html#valid-e-mail-address If the entered email address is invalid, the element will suffer from a type mismatch. Here are some possible solutions to allow the use of something like input type=login/username along with an email 1) change type=login to role=login (and thus allow a text/selec/email/whatever). Based on the feedback so far this is now my preferred solution. 2) add a role to form element and have the browsers continue to rely on id/name/class
Re: [whatwg] RFC: input type=username
Your suggestion sounds really interesting Thomas, I will have a read over it. I agree that if your username field will be in the form of an email address, then simply use type=username with a pattern to facilitate email validation. Not sure if that is really even needed at that point anyway because you are not really concerned over a well formed email address. If that was a problem, it would have been detected during registration. Schalk Neethling -Original Message- From: Thomas Broyer [mailto:t.bro...@gmail.com] Sent: Thursday, May 06, 2010 12:09 PM To: Markus Ernst Cc: Schalk Neethling; WHATWG List; Steve Dennis Subject: Re: [whatwg] RFC: input type=username On Thu, May 6, 2010 at 11:51 AM, Markus Ernst derer...@gmx.ch wrote: Am 05.05.2010 23:06 schrieb Schalk Neethling: The way I see it is that instead of browsers traversing the DOM looking for an input field of either id=username or name=username or even class=username, they now only have to look for an input of type username. Makes it a lot easier for both developers and browser vendors as they now only have to look for an input of type username and gives developers the freedom to use any name, id or class. But in many cases the username is an e-mail address, then you get a conflict with type=email. type=email is expected to (depending on the browser) allow you to search into/autocomplete from your address book. I really don't see a conflict here, it's not about syntax, it's about semantics (otherwise, just use a pattern= constraint). But actually, I'm not convinced type=username is required (or even useful). We're told that Cookies are bad for security and shouldn't be used for authentication (or other sensible data), so spec'ing this in HTML, which is expected to live for tens of years, would really be a Bad Thing (tm). It has been proposed earlier (a year and a half ago, at least) to reconcile Cookie-based auth with HTTP-auth, and that could be a way to tell the browser which form and/or which fields in the page are related to login. I posted a first draft of such a thing more than a year ago: http://tools.ietf.org/html/draft-broyer-http-cookie-auth I worked a bit on it since then to answer the feedback but I'm far from an -01 draft (I'd like to rewrite it from scratch actually...) http://github.com/tbroyer/http-cookie-auth -- Thomas Broyer /tɔ.ma.bʁwa.je/
Re: [whatwg] RFC: input type=username
On Thu, May 6, 2010 at 12:12 PM, Mounir Lamouri wrote: On 05/06/2010 12:09 PM, Thomas Broyer wrote: On Thu, May 6, 2010 at 11:51 AM, Markus Ernst derer...@gmx.ch wrote: Am 05.05.2010 23:06 schrieb Schalk Neethling: The way I see it is that instead of browsers traversing the DOM looking for an input field of either id=username or name=username or even class=username, they now only have to look for an input of type username. Makes it a lot easier for both developers and browser vendors as they now only have to look for an input of type username and gives developers the freedom to use any name, id or class. But in many cases the username is an e-mail address, then you get a conflict with type=email. type=email is expected to (depending on the browser) allow you to search into/autocomplete from your address book. I really don't see a conflict here, it's not about syntax, it's about semantics (otherwise, just use a pattern= constraint). The input type='email' isn't only about semantic. The browser has to check if the email is valid according to HTML5 specifications. Please, have a look at: http://dev.w3.org/html5/spec/forms.html#valid-e-mail-address If the entered email address is invalid, the element will suffer from a type mismatch. Of course, just like type=url requires the URL to be a valid absolute URL, while hinting browsers to autocomplete based on your bookmarks and/or search history (note: not your account manager). Would you use a type=number (that some browsers would present as a spinner box) if the usernames were only digits? (BTW, the syntax for an e-mail address to be considered valid is quite lax, and can be easily reproduced using a pattern= constraint, as I already said) -- Thomas Broyer /tɔ.ma.bʁwa.je/
Re: [whatwg] RFC: input type=username
On Thu, 2010-05-06 at 14:54 +0200, Thomas Broyer wrote: On Thu, May 6, 2010 at 12:12 PM, Mounir Lamouri wrote: On 05/06/2010 12:09 PM, Thomas Broyer wrote: On Thu, May 6, 2010 at 11:51 AM, Markus Ernst derer...@gmx.ch wrote: Am 05.05.2010 23:06 schrieb Schalk Neethling: The way I see it is that instead of browsers traversing the DOM looking for an input field of either id=username or name=username or even class=username, they now only have to look for an input of type username. Makes it a lot easier for both developers and browser vendors as they now only have to look for an input of type username and gives developers the freedom to use any name, id or class. But in many cases the username is an e-mail address, then you get a conflict with type=email. type=email is expected to (depending on the browser) allow you to search into/autocomplete from your address book. I really don't see a conflict here, it's not about syntax, it's about semantics (otherwise, just use a pattern= constraint). The input type='email' isn't only about semantic. The browser has to check if the email is valid according to HTML5 specifications. Please, have a look at: http://dev.w3.org/html5/spec/forms.html#valid-e-mail-address If the entered email address is invalid, the element will suffer from a type mismatch. Of course, just like type=url requires the URL to be a valid absolute URL, while hinting browsers to autocomplete based on your bookmarks and/or search history (note: not your account manager). Would you use a type=number (that some browsers would present as a spinner box) if the usernames were only digits? (BTW, the syntax for an e-mail address to be considered valid is quite lax, and can be easily reproduced using a pattern= constraint, as I already said) I wouldn't say the syntax is lax, just that it allows a lot of variation. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] RFC: input type=username
Schalk Neethling writes: if your username field will be in the form of an email address, then simply use type=username with a pattern to facilitate email validation. Surely a major reason for having standard validation types is so web developers don't need to come up with patterns for these common things? It also avoids lots of different authors coming up with something different, and not getting it right. The validation needed to accurately match a valid e-mail address is surprisingly convoluted -- see for example the regular expression on this page: http://www.ex-parrot.com/pdw/Mail-RFC822-Address.html Not sure if that is really even needed at that point anyway because you are not really concerned over a well formed email address. If that was a problem, it would have been detected during registration. Sure, you aren't concerned that a user's correct username might not be a valid e-mail address. But if a user tries to submit something that isn't a syntactically correct e-mail address, then he must have mis-typed his username. Using type=email allows the browser to alert him to this, so he can fix it. Without that, he has to wait for server-side validation. Smylers
Re: [whatwg] RFC: input type=username
Smylers, I understand what you mean but, then I have to agree with Thomas that you can then use an input of type username and use the pattern to validate the email address. Schalk -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Smylers Sent: Thursday, May 06, 2010 3:18 PM To: whatwg@lists.whatwg.org Subject: Re: [whatwg] RFC: input type=username Schalk Neethling writes: if your username field will be in the form of an email address, then simply use type=username with a pattern to facilitate email validation. Surely a major reason for having standard validation types is so web developers don't need to come up with patterns for these common things? It also avoids lots of different authors coming up with something different, and not getting it right. The validation needed to accurately match a valid e-mail address is surprisingly convoluted -- see for example the regular expression on this page: http://www.ex-parrot.com/pdw/Mail-RFC822-Address.html Not sure if that is really even needed at that point anyway because you are not really concerned over a well formed email address. If that was a problem, it would have been detected during registration. Sure, you aren't concerned that a user's correct username might not be a valid e-mail address. But if a user tries to submit something that isn't a syntactically correct e-mail address, then he must have mis-typed his username. Using type=email allows the browser to alert him to this, so he can fix it. Without that, he has to wait for server-side validation. Smylers
Re: [whatwg] RFC: input type=username
On 5/4/10 12:08 AM, Eitan Adler wrote: 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. Firefox's existing password manager doesn't do this. Roughly, it assumes the username field is the first input type=text before the first input type=password in a form. My previous thinking about this problem was to allow tagging the form element with the names of the inputs to be used for the login. For example: form loginfields=abc,def input type=text name=abc input type=password name=def /form But I agree with what Jonas noted earlier in this thread; improving the login experience needs a broader solution than just tweaking HTML attributes. Additionally, I suspect that the sites with currently-broken login forms are the ones least likely to change... It's not hard to make existing sites work with existing password managers, so I don't think it's a problem more markup will solve. Justin
Re: [whatwg] RFC: input type=username
On Tue, May 4, 2010 at 8:21 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 5/4/10 10:56 PM, Dirk Pranke wrote: What I would like to offer is a way to control some amount of the sign-in/sign-out experience while improving the security, by at least giving an in-page way to trigger sign-in / sign-out (the actual mechanism of collecting the credentials and performing the sign-in would be done by the browser without page intervention, where possible, for security reasons). So this would be something pages opt into? Yes. I also imagine people submitting user scripts that could rewrite existing login forms into forms using the new tags. If not, how would the following sign-in workflows (taken from two banking sites I've dealt with recently) work: Workflow 1: 1) Site prompts user for only a username. 2) After user enters a username, site responds with a Hello, __firstname__ (with either the first name corresponding to the username filled in or a random one generated if there's no such account) and two security questions. 3) After the user correctly answers the two security questions, he is presented with a previously-agreed-on image and phrase (to convince the user that the bank is in fact the bank) and 9 clickable buttons numbered 0-9. 4a) If the user has a mouse, the user clicks the buttons in the right order to enter their PIN (I believe a 7-digit or more number). Else go to 4b. 4b) If the user cannot use the mouse for some reason, the user can follow a link which associates each of the 10 buttons with one of a randomly chosen (each time you hit this screen, as far as I can see) set of 10 letters. The user can then type the letters that correspond to the desired numbers. Workflow 2: 1) Site prompts user for only a username. 2) After user enters a username, site responds with a page that has a password field and a bunch of buttons in the general shape of a qwerty keyboard. 3) The user enters a password in the password field. 4) The user also enters a different password (the site enforces that they're different during account setup) by clicking the correct buttons on the virtual keyboard. Various other banking sites I've dealt with have the previously-agree-on image and phrase thing going on, but these two are the ones that are creative with password input. In particular, the goal seems to be to defeat keyloggers by making replay of logged keystrokes be insufficient to log into the site. There is no question that people have dreamt up a large variety of mechanisms for logging into web sites. It would be difficult to support all of them out of the box, and certainly we would need to eventually extend the specs that Mozilla has defined to talk about how to support two-factor auth and other schemes like the ones you describe, if we can't figure out how to move them to more secure mechanisms. In particular, allowing a safe login from a compromised machine is, to say the least, somewhat challenging :( Both the Mozilla Account Manager and the scheme I'm talking about -- which again, builds on top of the account manager -- at least have the advantages that (a) they take the actual typing in of the password out of page and (b) they make the job of password managers far more reliable. Those alone should deliver enough benefit to make these ideas interesting, in my opinion. -- Dirk
Re: [whatwg] RFC: input type=username
Eitan Adler: 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. I agree with whomever mentioned that form role=login seems more appropriate. Anyhow, I wondered whether it makes sense to apply microformats to such forms, perhaps reusing ‘hcard’: form class=vcard role=login method=post action=./ input type=text name=username class=nickname input type=password name=password input type=submit /form Nick and user name are probably not the same all that often and differ by site, so this probably doesn’t make sense at all. Still, form field semantics (‘name’/‘id’ and ‘class’ or ‘role’) may improve through some kind of standardization, although names shouldn’t be as clumsy as in RFC 3106 (ECML: Field Specifications for E-Commerce) when applied to HTML forms. form action=http://ecom.example.com; method=post class=Ecom fieldset class=Payment-Card legendPlease enter card information/legend label class=NameYour name on the card input type=text name=Ecom_Payment_Card_Name size=40 /label label class=NumberThe card number input type=text name=Ecom_Payment_Card_Number size=19 /label label class=ExpDateExpiration date (MM YY) input type=month class=Month name=Ecom_Payment_Card_ExpDate_Month size=2 input type=year class=Year name=Ecom_Payment_Card_ExpDate_Year size=4 /label input type=hidden class=Protocol name=Ecom_Payment_Card_Protocol /fieldset input type=hidden class=SchemaVersion name=Ecom_SchemaVersion value=http://www.ecml.org/version/1.1; input type=submit input type=reset /form
Re: [whatwg] RFC: input type=username
I personally like the idea of having a type of username for an input field, makes sense based on the use case. Kind Regards, Schalk Neethling -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Dirk Pranke Sent: Wednesday, May 05, 2010 8:20 AM To: Boris Zbarsky Cc: whatwg@lists.whatwg.org Subject: Re: [whatwg] RFC: input type=username On Tue, May 4, 2010 at 8:21 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 5/4/10 10:56 PM, Dirk Pranke wrote: What I would like to offer is a way to control some amount of the sign-in/sign-out experience while improving the security, by at least giving an in-page way to trigger sign-in / sign-out (the actual mechanism of collecting the credentials and performing the sign-in would be done by the browser without page intervention, where possible, for security reasons). So this would be something pages opt into? Yes. I also imagine people submitting user scripts that could rewrite existing login forms into forms using the new tags. If not, how would the following sign-in workflows (taken from two banking sites I've dealt with recently) work: Workflow 1: 1) Site prompts user for only a username. 2) After user enters a username, site responds with a Hello, __firstname__ (with either the first name corresponding to the username filled in or a random one generated if there's no such account) and two security questions. 3) After the user correctly answers the two security questions, he is presented with a previously-agreed-on image and phrase (to convince the user that the bank is in fact the bank) and 9 clickable buttons numbered 0-9. 4a) If the user has a mouse, the user clicks the buttons in the right order to enter their PIN (I believe a 7-digit or more number). Else go to 4b. 4b) If the user cannot use the mouse for some reason, the user can follow a link which associates each of the 10 buttons with one of a randomly chosen (each time you hit this screen, as far as I can see) set of 10 letters. The user can then type the letters that correspond to the desired numbers. Workflow 2: 1) Site prompts user for only a username. 2) After user enters a username, site responds with a page that has a password field and a bunch of buttons in the general shape of a qwerty keyboard. 3) The user enters a password in the password field. 4) The user also enters a different password (the site enforces that they're different during account setup) by clicking the correct buttons on the virtual keyboard. Various other banking sites I've dealt with have the previously-agree-on image and phrase thing going on, but these two are the ones that are creative with password input. In particular, the goal seems to be to defeat keyloggers by making replay of logged keystrokes be insufficient to log into the site. There is no question that people have dreamt up a large variety of mechanisms for logging into web sites. It would be difficult to support all of them out of the box, and certainly we would need to eventually extend the specs that Mozilla has defined to talk about how to support two-factor auth and other schemes like the ones you describe, if we can't figure out how to move them to more secure mechanisms. In particular, allowing a safe login from a compromised machine is, to say the least, somewhat challenging :( Both the Mozilla Account Manager and the scheme I'm talking about -- which again, builds on top of the account manager -- at least have the advantages that (a) they take the actual typing in of the password out of page and (b) they make the job of password managers far more reliable. Those alone should deliver enough benefit to make these ideas interesting, in my opinion. -- Dirk
Re: [whatwg] RFC: input type=username
On 5/05/2010, at 9:09 PM, Christoph Päper wrote: Eitan Adler: 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. I agree with whomever mentioned that form role=login seems more appropriate. Anyhow, I wondered whether it makes sense to apply microformats to such forms, perhaps reusing ‘hcard’: form class=vcard role=login method=post action=./ input type=text name=username class=nickname input type=password name=password input type=submit /form Nick and user name are probably not the same all that often and differ by site, so this probably doesn’t make sense at all. Still, form field semantics (‘name’/‘id’ and ‘class’ or ‘role’) may improve through some kind of standardization, although names shouldn’t be as clumsy as in RFC 3106 (ECML: Field Specifications for E-Commerce) when applied to HTML forms. form action=http://ecom.example.com; method=post class=Ecom fieldset class=Payment-Card legendPlease enter card information/legend label class=NameYour name on the card input type=text name=Ecom_Payment_Card_Name size=40 /label label class=NumberThe card number input type=text name=Ecom_Payment_Card_Number size=19 /label label class=ExpDateExpiration date (MM YY) input type=month class=Month name=Ecom_Payment_Card_ExpDate_Month size=2 input type=year class=Year name=Ecom_Payment_Card_ExpDate_Year size=4 /label input type=hidden class=Protocol name=Ecom_Payment_Card_Protocol /fieldset input type=hidden class=SchemaVersion name=Ecom_SchemaVersion value=http://www.ecml.org/version/1.1; input type=submit input type=reset /form I don't know if it's relevant, but if we're thinking backwards compatibility, keep in mind earlier versions of ASP.NET only allow one form per page, so wrapping a login in a form tag isn't really an option. Someone tell me if I'm wrong on that though, I'm just a designer :) -- Steve Dennis www.subcide.com
Re: [whatwg] RFC: input type=username
The way I see it is that instead of browsers traversing the DOM looking for an input field of either id=username or name=username or even class=username, they now only have to look for an input of type username. Makes it a lot easier for both developers and browser vendors as they now only have to look for an input of type username and gives developers the freedom to use any name, id or class. Kind Regards, Schalk -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Steve Dennis Sent: Wednesday, May 05, 2010 10:40 PM To: Christoph Päper Cc: WHATWG List Subject: Re: [whatwg] RFC: input type=username On 5/05/2010, at 9:09 PM, Christoph Päper wrote: Eitan Adler: 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. I agree with whomever mentioned that form role=login seems more appropriate. Anyhow, I wondered whether it makes sense to apply microformats to such forms, perhaps reusing hcard: form class=vcard role=login method=post action=./ input type=text name=username class=nickname input type=password name=password input type=submit /form Nick and user name are probably not the same all that often and differ by site, so this probably doesnt make sense at all. Still, form field semantics (name/id and class or role) may improve through some kind of standardization, although names shouldnt be as clumsy as in RFC 3106 (ECML: Field Specifications for E-Commerce) when applied to HTML forms. form action=http://ecom.example.com; method=post class=Ecom fieldset class=Payment-Card legendPlease enter card information/legend label class=NameYour name on the card input type=text name=Ecom_Payment_Card_Name size=40 /label label class=NumberThe card number input type=text name=Ecom_Payment_Card_Number size=19 /label label class=ExpDateExpiration date (MM YY) input type=month class=Month name=Ecom_Payment_Card_ExpDate_Month size=2 input type=year class=Year name=Ecom_Payment_Card_ExpDate_Year size=4 /label input type=hidden class=Protocol name=Ecom_Payment_Card_Protocol /fieldset input type=hidden class=SchemaVersion name=Ecom_SchemaVersion value=http://www.ecml.org/version/1.1; input type=submit input type=reset /form I don't know if it's relevant, but if we're thinking backwards compatibility, keep in mind earlier versions of ASP.NET only allow one form per page, so wrapping a login in a form tag isn't really an option. Someone tell me if I'm wrong on that though, I'm just a designer :) -- Steve Dennis www.subcide.com=
[whatwg] RFC: input type=username
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/
Re: [whatwg] RFC: input type=username
On Tue, May 4, 2010 at 10:08 AM, Eitan Adler eitanadlerl...@gmail.com wrote: 3) Currently autofill for usernames looks for something like id=username or name=username. However on certain websites this fails. Why would a site which doesn't cooperate with today's autofill features choose to cooperate with your proposal? sites typically are either stupid or evil, and neither are likely to embrace new standards.
Re: [whatwg] RFC: input type=username
On 4/05/2010, at 9:07 AM, timeless wrote: On Tue, May 4, 2010 at 10:08 AM, Eitan Adler eitanadlerl...@gmail.com wrote: 3) Currently autofill for usernames looks for something like id=username or name=username. However on certain websites this fails. Why would a site which doesn't cooperate with today's autofill features choose to cooperate with your proposal? sites typically are either stupid or evil, and neither are likely to embrace new standards. Because id=username isn't a standard as such. Having it specified in a spec is likely to help people adopt it more quickly. Saying why bother? about all the broken sites on the web totally defeats the purpose of what everyone here's trying to achieve. -- Steve Dennis www.subcide.com
Re: [whatwg] RFC: input type=username
On 4 May 2010, at 09:07, timeless wrote: On Tue, May 4, 2010 at 10:08 AM, Eitan Adler eitanadlerl...@gmail.com wrote: 3) Currently autofill for usernames looks for something like id=username or name=username. However on certain websites this fails. Why would a site which doesn't cooperate with today's autofill features choose to cooperate with your proposal? Sites may not work correctly with autofill because their login forms are too complex or confusing the auto-fill feature (and sometimes login forms are complex/unusual – users may have option to log in to different sections of the site, with different security options). I don't think type=username is good solution, but I agree that autofill needs help. Sites often use e-mail address as login. There would be conflict between type=email and type=username. I have wiki that has password field on edit page (you don't log in before starting an edit, you simply type password before submitting the change). It completely confuses Opera's autofill which tries to save page title field as login name. Perhaps new values for autocomplete attribute would do the trick? autocomplete=login, autocomplete=not-login? (latter meaning you can autocomplete, but don't autofill when logging in). It would be nice to have autodiscovery for OpenID logins: input type=url autocomplete=login? autocomplete=openid? Another problem is the same login form appearing in multiple places on the site (usually slighly different form is part of site's layout, and different one is presented when user is forced to log in). Sometimes autofill sees such forms as same, and sometimes it doesn't. Auto-fill information is often lost when sites are redesigned. It would be nice if autofill could remember values from registration form and automatically use them for logging in. Users usually aren't asked to log in after registering, so there's no opportunity for the browser to save login details immediately. For this something like Realm value in HTTP auth would be helpful (perhaps as an attribute on form or input). Same realm across different forms would allow browser to save same details for all of them. -- regards, Kornel
Re: [whatwg] RFC: input type=username
I don't think type=username is good solution, but I agree that autofill needs help. Sites often use e-mail address as login. There would be conflict between type=email and type=username. I could imagine one two solutions here. 1) Change type=username to role=username which makes more sense anyway (a username field is actually a text field) 2) Allow multiple types per input field. This IMHO is a bad idea. Another problem is the same login form appearing in multiple places on the site (usually slighly different form is part of site's layout, and different one is presented when user is forced to log in). Sometimes autofill sees such forms as same, and sometimes it doesn't. Auto-fill information is often lost when sites are redesigned. The goal of type=username is to indicate to the UA which form is the login form. This would allow features such as remember me and autofill to be done in the UA instead of in the browser. It would be nice if autofill could remember values from registration form and automatically use them for logging in. Users usually aren't asked to log in after registering, so there's no opportunity for the browser to save login details immediately. Firefox is fairly good about this - asking me to remember passwords from registrations forms. The goal of my type=username proposal was to provide some indication to the UA that a particular form is a login form. Another idea is to allow forms to have roles. form ... role=[register|login|search] would be a decent alternative to input type=username There are two major places I could see this improving things. One was already mentioned: autofill. The second is screen readers. Instead of having to read out the entire form the UA could just ask Register for this site? or Log in now?. -- Eitan Adler
Re: [whatwg] RFC: input type=username
On Tue, May 4, 2010 at 2:02 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, May 4, 2010 at 1:53 PM, Dirk Pranke dpra...@chromium.org wrote: On Tue, May 4, 2010 at 12:08 AM, Eitan Adler eitanadlerl...@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
