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

[John Knottenbelt]

Hi Rich,


On Wed, Feb 16, 2011 at 6:03 PM, Rich Tibbett <richt at opera.com> wrote:

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


I agree that clicking on the <device> element to bring up an
async authorisation request works well because it corresponds strongly
to the user's will to start and stop access to the device. However, I think
that we should not be trying to save the user a click, because that would
risk bothering the user with a dialog before they have made their intention
to grant access to the device explicit. The principal application of
<device> is to grant access to webcam devices which, I think, is sensitive
enough to warrant the user having to initiate the authorisation process.


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


Since the primary use cases for this element are applications that require
scripting, I'm not sure that it make sense to worry about <device> when JS
is turned off or unavailable. Indeed, the applications that will use
<device> will probably require JavaScript for other purposes anyway. if JS
is disabled, I would expect those applications to render the usual, "This
page requires JS" message.


By "fallback" do you mean fallback content (if the device is unavailable)?
If so, doesn't section 3.2.5.1.6 of HTML5:
http://dev.w3.org/html5/spec/Overview.html#embedded-content-0 cover this?


If the user agent doesn't understand the <device> tag, it should behave in
the same way as an HTML 4 user agent behaves when it encounters any HTML5
element, e.g. <video>. I think it may be worth revisiting the intention to
make <device> a

void element, so that some inner content can be rendered instead (like
<video>).


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


We could make UI design easier by supporting a small set of CSS rules to
skin the <device> element.


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


The big strength of the <device> element, just like <input type=file>, is
that it requires a user click to bring up the authorisation dialog. I think
that it's a better approach to start with this tried-and-tested security
model and fix problems such as skinning, rather than to start with the a
Javascript API and add in a security model later.


Cheers


John

On Wed, Feb 16, 2011 at 6:03 PM, Rich Tibbett <richt at opera.com> wrote:

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