Andrei Popescu wrote:
Hi Anne,
On Wed, Feb 16, 2011 at 12:36 PM, Anne van Kesteren<ann...@opera.com> wrote:
On Tue, 15 Feb 2011 17:48:24 +0100, Leandro Graciá Gil
<leandrogra...@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
