[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] Real-time networking in web applications and games
On Mon, 03 May 2010 23:59:19 +0200, Mark Frohnmayer mark.frohnma...@gmail.com wrote: Hey all, In continuation of the effort to make browsers a home for real-time peer to peer applications and games without a plugin, I've done a bit of digging on the spec. Currently the spec contains section 4.11.6.2 (Peer-to-peer connections) that appears to present a high-level peer-to-peer api with separate functionality for peer connection and transmission of text, images and streamed data interleaved in some unspecified protocol. Also referenced from the spec is WebSocket, a thin-layer protocol presenting what amounts to a simple guaranteed packet stream between client and server. For the purposes of discussion there seem to be two distinct issues - peer introduction, where two clients establish a direct connection via some trusted third party, and data transmission protocol which could range from raw UDP to higher-level protocols like XML-RPC over HTTP. For real-time games, specific concerns include flow control, protocol overhead and retransmission policy; thus most real-time games implement custom network protocols atop UDP. Peer introduction is also important - responsiveness can often be improved and hosting bandwidth costs reduced by having peers connect directly. For other p2p apps (chat, etc), specific control of flow and data retransmission may be less (or not) important, but peer introduction is still relevant. In reading of the current state of the spec's p2p section, it appears to be poorly suiting to real-time gaming applications, as well as potentially over-scoped for specific p2p applications. To demonstrate an alternative approach, the initial prototype of the TorqueSocket plugin now works (build script for OS X only). The API as spec'd here: http://github.com/nardo/torque_sockets/raw/master/TorqueSocket_API.txt now actually functions in the form of an NPAPI plugin. I recorded a capture of the javascript test program here: http://www.youtube.com/watch?v=HijKc5AwYHM if you want to see it in action without actually building the example. This leads me to wonder about (1) the viability of including peer introduction into WebSocket as an alternative to a high-level peer to peer interface in the spec, (2) including a lower-level unreliable protocol mode, either as part or distinct from WebSocket, and (3) who, if anyone, is currently driving the p2p section of the spec. Any feedback welcome :). Cheers, Mark I'm an old gamedev recently turned browserdev so this is of particular interest to me, especially as I'm currently working on WebSockets. WebSockets is a nice step towards multiplayer games in browsers and will be even better once binary frames are speced out but as Mark says (depending on the nature of the game) gamedevs are most likely going to want to make their own UDP based protocol (in client-server models as well). Has there been any discussions on how this would fit under WebSockets? Opera Unite can be mentioned as an interesting side note, it does peer introduction as well as subnet peer detection, but again that's TCP only. -- Erik Möller Core Developer Opera Software
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
[whatwg] WebSockets cookies
establish a WebSocket connection: [[ 15. If the client has any cookies that would be relevant to a resource accessed over HTTP, if secure is false, or HTTPS, if it is true, on host host, port port, with resource name as the path (and possibly query parameters), then add to fields any HTTP headers that would be appropriate for that information. [HTTP] [COOKIES] ]] Adding an HTTP header seems to allow HTTP syntax that is incompatible with WebSocket fields syntax. For instance, whitespace before the colon, horizontal tab instead of space after the colon, continuation lines, comments, escapes... Also, does it say to add a single entry to fields with all headers or one entry per header? -- Simon Pieters Opera Software
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] Ping + Ping-prefix meta element.
On 26.04.2010 22:17, Roger Hågensen wrote: ... Oh, and could someone on the HTML5 list poke some of the guys over there and see if a ping attribute for the body tag in a similar vein could be considered? ... If by HTML5 list you happen to mean the mailing list of the W3C HTML WG...: the WG decided to remove the ping attribute earlier this year; it's gone from the W3C spec draft. Best regards, Julian
Re: [whatwg] why double downloading of ogg videos ?
On 17.04.2010 09:36, Robert O'Callahan wrote: This is an implementation issue rather than a spec issue. It's basically just because of the way the Firefox network cache works. When we play an Ogg video we generally don't download the data in a single continuous HTTP GET; if the server supports byte Range requests, we actually seek to various places in the stream at different times to fetch metadata etc. So the network cache never sees a request that returns the complete resource, and never caches it. We do have a special media cache that's good at caching fetched media data, but Save As doesn't know about the media cache. We could fix that, but it would be somewhat complex and to be honest it's probably not worth it. ... Rob, related question: do you do the partial GET only for getting access to metadata, or are you also using it for seeking in the video? (As opposed to downloading it once into the media cache, and then use that content throughout?) Best regards, Julian
Re: [whatwg] why double downloading of ogg videos ?
On 04.05.2010 16:16, Julian Reschke wrote: Rob, related question: do you do the partial GET only for getting access to metadata, or are you also using it for seeking in the video? (As opposed to downloading it once into the media cache, and then use that content throughout?) Best regards, Julian I just managed to test with a larger, non-local OGV file, and Mozilla indeed seems to use partial GETs when seeking/skipping. Great. Short question: is it intentional that the partial GETs do not use an If-Match: request header? Best regards, Julian
Re: [whatwg] Do we really need to introduce a device element for giving access to webcams and mikes?
The device was added by Ian Hickson in response to some of the work in the W3C DAP working group. The original intent was to make sure the user are actively grant permission to a particular device camera or microphone instead of just click okay since some malicious site can just capture and post it on the internet. Here is a reference to the work in W3C DAP: http://dev.w3.org/2009/dap/camera/Overview.html Some threads on the topic: http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0248.html http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0194.html Thanks Dzung Tran, -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Julien Cayzac Sent: Monday, May 03, 2010 07:41 PM To: whatwg@lists.whatwg.org Subject: Re: [whatwg] Do we really need to introduce a device element for giving access to webcams and mikes? On Tue, May 4, 2010 at 11:37 AM, Julien Cayzac julien.cay...@gmail.com wrote: I am not sure if I get your point here: are you saying that using the webcam locally in a canvas and somehow transmitting the webcam video over the network are two independent permissions to grant? If so, how would you detect the latter, since by allowing the page to manipulate the video in canvas you would give it permission to use toDataURL() too, so it could still transmit frames to the server or to other party if a ConnectionPeer is involved? To answer my own question: by raising the origin-clean flags of the canvas element the webcam was attached to. Now, I see no reference to any interaction between device and canvas mentionned in http://dev.w3.org/html5/html-device/ Julien. -- Julien Cayzac http://julien.cayzac.name/ skype://jcayzac?chat
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] Ping + Ping-prefix meta element.
On Tue, 4 May 2010, Julian Reschke wrote: On 26.04.2010 22:17, Roger Hågensen wrote: ... Oh, and could someone on the HTML5 list poke some of the guys over there and see if a ping attribute for the body tag in a similar vein could be considered? ... If by HTML5 list you happen to mean the mailing list of the W3C HTML WG...: the WG decided to remove the ping attribute earlier this year; it's gone from the W3C spec draft. It's still in the WHATWG draft, however. Roger: Your input has been added to the list of proposals to consider. There's no ETA on how long that will take, sometimes it takes me many months to get to each last piece of feedback. -- 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 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
[whatwg] onshow event
I see in the html5 spec an 'onshow' event but no text describing when the 'show' event is triggered. I've poked at FF 3.5 and Opera and can not get it to fire. But I may be completely confused on when it should fire. It would be wonderful if an element had an event that would fire when that particular element is shown on the page. This might be due to the display attribute changing or it might be due to it scrolling into view. onshow appeared to be the closest match to this. The case I'm trying to do is write a dodad which needs to be initialized but if I call the initialization method while it is hidden, the height and width come back 0 and the code doesn't work. I could add a hook into the parent to call the init when the parent decides to show the element but it would be nicer if I didn't have to do that. It would be nice if the element knew it was time to initialize itself based upon it being shown on the page. Also, I can't temporarily change the elements display attribute because its display is not the one that is hiding it. It is actually hidden (initially) but two of its parents. It seems like this would be a fairly frequent desire. Perhaps there is already an idiom for this. Thank you, Perry
