[whatwg] Device element and the lifetime of the stream objects

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 
as well just implement a Javascript API to call the async authorization 
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?

The <device> element requires JavaScript to do anything useful. Without 
Javascript all the authorization interfaces will still work and users 
will still go through them to authorize access to their device but 
then...nothing will happen if the page is not running JavaScript. That's 
not great.

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 
authorizations.

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 
JavaScript with vendor API prefixes in preparation for a final standard 
approach.

We're doing due diligence on both options so it's worth having this 
discussion and seeing what other implementers think.

Cheers,

Rich

Received on Wednesday, 16 February 2011 10:03:08 UTC