Re: [whatwg] Media sink device selection on /
On Fri, Apr 11, 2014 at 6:23 PM, Edward O'Connor wrote: > >> The consensus opinion at WebRTC and MediaCapture seemed to be that > >> the ability to let an app say "which of these 5 microphones do you > >> want?" is more amenable to creating good apps than leaving this UI to > >> the browser chrome. > > > > Seems to me that the privacy aspects (the fingerprinting > > vulnerabilities from exposing this data), and the abuse aspects > > (giving hostile sites the ability to access all the user's devices if > > any are made available) would trump this. Surely we can rely on user > > agents to provide nice UIs. > The fingerprinting could be pretty specific, too. For example, my apple TV advertises itself with a custom AirPlay name. I agree with Ian. For instance, on iOS we provide features that allow > Web developers to take AirPlay into account when building custom video > controls, but we do not expose the list of AirPlay targets to Web > content. > Some other issues: - The browser will give a consistent UI. I don't get a different "Save As" dialog for each site, and I shouldn't get a different "which mic do you want to use?" dialog for each site either. - The browser will give a UI. My guess is that the vast majority of web apps wouldn't provide a selection UI *at all* for mics or speakers, and just use the default. - Web apps shouldn't need to implement basic UI for things like this, just like they shouldn't have to implement their own Save As dialogs. That's the platform's job. -- Glenn Maynard
Re: [whatwg] Media sink device selection on /
Hi, >> The consensus opinion at WebRTC and MediaCapture seemed to be that >> the ability to let an app say "which of these 5 microphones do you >> want?" is more amenable to creating good apps than leaving this UI to >> the browser chrome. > > Seems to me that the privacy aspects (the fingerprinting > vulnerabilities from exposing this data), and the abuse aspects > (giving hostile sites the ability to access all the user's devices if > any are made available) would trump this. Surely we can rely on user > agents to provide nice UIs. I agree with Ian. For instance, on iOS we provide features that allow Web developers to take AirPlay into account when building custom video controls, but we do not expose the list of AirPlay targets to Web content. Ted
Re: [whatwg] Proposal: requestBackgroundProcessing()
On Thu, 20 Feb 2014, Ashley Gullen wrote: > > We're building a browser-based P2P multiplayer engine on top of WebRTC > DataChannels. You can try out our work-in-progress here: > http://www.scirra.com/labs/multiplayer/test1/ > > The first player in to a room is assigned the host, and all other > subsequently joining peers connect to the host with WebRTC DataChannels > and start exchanging game data. Like all responsible HTML5 games, it > runs based on a requestAnimationFrame loop. requestAnimationFrame() is for animations, not for logic. For logic, your better bet is to use a worker or, at worst, setInterval(). > To prevent multiplayer games commonly hanging, perhaps there could be a > new API to request that a page can keep running at full capacity even in > the background, such as window.requestBackgroundProcessing(). Workers are the mechanism for running code in the background. I would strongly recommend not using a peer server architecture, though. Doing this requires trusting the client, which is highly dubious. A hostile player could just inject arbitrary code into your logic, and subtly cheat without being detected. It also means that handling the host crashing or closing their laptop or going into a tunnel is different than the same for another player, which is a sucky experience for everyone. On Thu, 20 Feb 2014, Glenn Maynard wrote: > On Thu, Feb 20, 2014 at 12:35 PM, Rik Cabanier wrote: > > > > Is WebRTC available in a worker? > > I don't know, but if not, fixing that is probably closer to the right > direction than letting people run fast timers in minimized UI threads. Yeah. If WebRTC isn't being exposed to workers, I recommend bringing that up with the editor of the WebRTC spec. On Thu, 20 Feb 2014, Ashley Gullen wrote: > > There's a lot of worker features that aren't widely supported yet, like > rendering to canvas with WebGL and 2D, Web Audio support, inputs, > various APIs like speech and fullscreen, so I don't think that's > practical right now. Presumably your server logic doesn't need to be fullscreen... On Thu, 20 Feb 2014, Ashley Gullen wrote: > > Since it's a peer-to-peer engine, the user acting as the server is also > a participant in the game. This means the server is also running the > full game experience with rendering and audio. That part of the logic should be in the tab. Then the tab just acts as a client to the server in the worker, in the same way that the other clients for the other players do. > The game logic is tied to rAF, since we intend to step the world once > per screen draw, including for the player acting as a server. Different players are going to have different frame rates, so it doesn't make sense to make one player's frame rate more important than another's. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Various autocomplete="" topics
Hi, Ian wrote: > Is there any reason to have two fields here, why not just "new" both > times? That works for me. Browsers can supply the same value for multiple autocomplete=new-password fields in the same form. > Also, should we have an "old" field for the old password, or is the > lack of an autofill field sufficient? I think it makes sense to have an old/current password token, for change password forms. It also helps to distinguish sign up forms from sign in forms, as Mike mentioned in the bug. > I've filed a bug to track this: >https://www.w3.org/Bugs/Public/show_bug.cgi?id=25236 > > It needs multiple vendors on board to make progress. […] > I've filed a bug to track this: >https://www.w3.org/Bugs/Public/show_bug.cgi?id=25237 > > It needs multiple vendors on board to make progress. Chrome has also expressed interest on both of these bugs. >> Also, consider the case of login forms without username fields. You >> see this sort of thing a lot these days, when sites remember who was >> last logged in: >> >> >> Password for hober: >> Not hober? Click here to sign in. >> >> >> It's difficult for tools to manage the user's auth info for such >> pages. How can tools discover what the username is? The obvious >> solution, in a world with autocomplete=username, would be to add >> >> to the form. > > So far, autocomplete="" hasn't applied to . This > would be a bit weird, giving it a different meaning than usual > (providing information to the UA, rather than getting information from > the UA). I'm a bit skeptical of this kind of overloading. It is kind of weird. Given that, maybe this case should have new syntax. I'm OK with overloading autocomplete=username or with new syntax. I don't have a particular color to suggest for the bikeshed. > For the real submission case, I guess what we want is a way to say > "autocomplete=off" after the fact, basically. An HTTP header seems > like the most obvious solution. > >https://www.w3.org/Bugs/Public/show_bug.cgi?id=25239 > > Again, these need multiple vendors on board to make progress. Browsers are moving away from respecting autocomplete=off. I don't think we should be adding a new but basically equivalent mechanism. > I actually have a similar problem with purely JS-handled forms even > unrelated to credentials. Because the form is never really submitted > (even if we reuse the submit infrastructure, we cancel the 'submit' > event and handle the work on the JS side), there's never an indication > to the UA that it should save the fields, and so autofill never works > right on these forms, even for things like postal addresses or e-mail > addresses. > > For the pure JS case, an API (probably on the itself) would > make sense and seems relatively easy. I've filed a bug on this: > >https://www.w3.org/Bugs/Public/show_bug.cgi?id=25238 This case is pretty weird. Authors are going out of their way to avoid using the built in platform features that would get them autofill saving for free. In some cases, they might be doing this precisely because they want to prevent autofill but can't count on autocomplete=off anymore. > The requestAutocomplete() API is a Chrome proprietary feature right > now so it's sort of acadmic, but: > > Why would this only apply to requestAutocomplete()? Surely it would be > just as important for the case where the user agent is filling in a > form without using that API. Agreed. I don't see the benefit of requestAutocomplete() here. Ted
Re: [whatwg] Additional details for invoking requestAutocomplete
Perhaps now is a more appropriate time for this discussion, given that requestAutocomplete is now published in the spec (!). -- Evan Stade On Mon, Mar 10, 2014 at 1:33 PM, Evan Stade wrote: > Hi WhatWG. > > Currently, requestAutocomplete lets a user agent provide the same user > experience across multiple sites for common data input flows. A site > describes the data it desires (via a form and autocomplete attributes), and > the user agent uses this information and what it knows about the user to > expedite data input. For example, if one of the form elements has > autocomplete=”cc-number” the browser might provide an experience tailored > for a payment flow, or if there’s an element with autocomplete=”bday” the > browser might use an experience that’s tailored for sharing identiy. > > We’ve found that there are some details of the interaction which might > affect the UX which cannot be inferred from the data inputs. We propose to > add an optional argument to the requestAutocomplete method. Thus invocation > would look like: > > form_element.requestAutocomplete(details); > > This |details| argument would be an object where key-value pairs provide > additional details regarding the request. The spec should define a set of > keys and associated data types which are recognized. There are currently > two key-value pairs we would like to add: > > key: “transactionAmount” > value: number > description: For data that is going to be applied towards a > transaction, the /maximum/ value of the transaction. The browser does not > guarantee that the returned payment instrument will work, but keeping the > transaction under this amount will increase the likelihood of receiving a > valid card number. > > key: “transactionCurrency” > value: string > description: a valid ISO 4217 currency code that describes the > currency for transactionAmount. If not provided, the default is “USD”. > > Justification? There are upper bounds on certain payment instruments, for > example different credit cards have different credit limits; a debit card > is linked to a bank account with a certain balance. It’s a much preferable > user experience to be able to catch these problems earlier rather than > waiting for the merchant to attempt the transaction and have it fail (or > have a user’s account overdrawn). Concretely, Chromium wants to handle > transactions over $2000 differently from transactions under that amount. > > Does this seem reasonable? > > > -- Evan Stade >
