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
[whatwg] aspect-ratio CSS rule?
It would be very sweet if you could actually enforce an element's aspect ratio using CSS, so you wouldn't have to rely on hacks in the line of http://lab.veille.jp/aspectratio/ anymore. This is especially useful when designing elastic interfaces that display videos. Example: Right column at http://www.veille.jp/ Julien -- Julien Cayzac http://julien.cayzac.name/ skype://jcayzac?chat
Re: [whatwg] aspect-ratio CSS rule?
On Wed, 5 May 2010, Julien Cayzac wrote: It would be very sweet if you could actually enforce an element's aspect ratio using CSS, so you wouldn't have to rely on hacks in the line of http://lab.veille.jp/aspectratio/ anymore. This is especially useful when designing elastic interfaces that display videos. Example: Right column at http://www.veille.jp/ I recommend bringing this up with the CSS working group at www-st...@w3.org. At this time, the WHATWG is only working on HTML. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Input URL State and Files object
Hi all, Awhile ago, it appears, the files object was removed from input type=url Is there currently a method for allowing cross-domain access to an image based on user input? At present, it seems a user must first download an image to their desktop, then drag the image into an HTML 5 host. Is this something that's intended to be handled in the future via event.dataTransfer? -Charles
Re: [whatwg] Input URL State and Files object
On 5/5/2010 12:42 PM, Ian Hickson wrote: On Wed, 5 May 2010, Charles Pritchard wrote: Awhile ago, it appears, the files object was removed frominput type=url files doesn't really make much sense for type=url... Do you mean type=file? Sorry, it didn't make much sense: I meant a FileList object which FileReader would use. Is there currently a method for allowing cross-domain access to an image based on user input? XMLHttpRequest is the intended way to do this. XMLHttpRequest relies upon CORS headers from the server; failing that.. Should a user intentional drag an image or URL object, or otherwise select one from their browser UI, the interaction is quite similar to the input type=file object. Only, with a remote resource. I'm sorry to have approached this so poorly; what I'm looking for is a solution to the following use case: A person is assembling a digital scrap-book, using a web application, of pictures they've found related to their love of kittens. Those that they've downloaded to their computer, they simply drag and drop into the application -- (File API, FileReader, ondrop). Those that they find on the internet, they drag their bookmark onto the application, drag the image onto the application, or simply, copy and paste the URL into an input type=url box.
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] Expanding the cite element
Dear WHATWG list participants, Forgive me if this conversation has been had before; I've just recently joined the list. Is there any value in adding an href or uri or similar attribute to the cite element to indicate a location for a work (or information about the work) or, in the case of a URI, an indicator that can be used as a reference programmatically? q has a cite attribute, so it seems to me that if we have a place to link to further information in q it makes sense to do so in cite. After all, whether an author quotes from a reference (q) or merely discusses it without quoting (cite), both of these would end up in a works cited in a traditional paper. Therefore, I think both should link (or refer) to somewhere. If it were a URI (and therefore not necessarily retrievable), it would help in cases where the same work gets referenced in slightly different ways: pAs Ashley Crandall Amos says in cite uri=http://example.com/books/crandall/linguisticmeans;Linguistic Means of Determining the Dates of Old English Literary Texts/cite ... Amos also mentions in cite uri=http://example.com/books/crandall/linguisticmeans;Linguistic Means/cite/p ✍ Best, Grant Simpson ¶ Senior Analyst/Programmer, Office of the Registrar ¶ Doctoral Student, Department of English ¶ Representative, IU Bloomington Professional Council Indiana University Bloomington
