[whatwg] Device element and the lifetime of the stream objects
richt at opera.com
Wed Feb 16 10:03:08 PST 2011
Andrei Popescu wrote:
> Hi Anne,
> On Wed, Feb 16, 2011 at 12:36 PM, Anne van Kesteren<annevk at opera.com> wrote:
>> On Tue, 15 Feb 2011 17:48:24 +0100, Leandro Graciá Gil
>> <leandrogracia at chromium.org> wrote:
>>> All feedback will be greatly appreciated.
>> This is just a thought. Instead of acquiring a Stream object asynchronously
>> there always is one available showing transparent black or some such. E.g.
>> navigator.cameraStream. It also inherits from EventTarget. Then on the
>> Stream object you have methods to request camera access which triggers some
>> asynchronous UI.
> I thought we were all trying to avoid asynchronous UI (dialogs,
> infobars, popups, etc), which is a solution that does not scale very
> well when many different APIs require it. This was one of the main
> reasons for trying a different approach.
We are also trying a different approach but we're not really coming up
with anything other than modal dialogs, no-authorization models or
policies; none of which are suitable for different reasons. One option
that works is, on <device> click, presenting some kind of async
authorization request. However, if we're going to do that then we might
request in the first place (in the process saving one user click).
>> Once granted an appropriately named event is dispatched on
>> Stream indicating you now have access to an actual stream. When the user
>> decides it is enough and turns of the camera (or something else happens)
>> some other appropriately named event is dispatched on Stream again turning
>> it transparent black again.
>> This also removes the need for the<device> element as has been mentioned
>> off-list. Basically, the idea was that<device> does not really help anyone.
> What do you mean exactly by this? The usecases are pretty clear.
>> It makes custom in-page UI harder, it does not prevent the need for
>> scripting, and it does not help with fallback.
> I was never under the impression we need to prevent the need for
> scripting. Why is that a goal?
will still go through them to authorize access to their device but
There's no fallback or interaction within non-scripted environments so a
HTML element seems to be the wrong level for integration.
As also mentioned above, in-page UI is harder if we force a particular
style for <device> elements (a button or otherwise) on to developers.
>> This is somewhat weird though :-)
> Agreed. And, as I said earlier, I thought the goal was to try
> something else than asynchronous permission dialogs. What has changed?
We've been looking at usability and user interface for <device> vs an
async JS API and are finding better ways to make multiple async JS APIs
work in our interfaces than we are for <device> element-based
It would also be easier for prototyping if we didn't make assumptions on
a <device> element. We can always jump to implementing a <device>
element later on but initially it might be good to prototype in
We're doing due diligence on both options so it's worth having this
discussion and seeing what other implementers think.
More information about the whatwg