RE: <input type=photo> etc as Capture API

Arve,
I understand that a webapp could arrange some hidden (or visible) markup that it then invokes with .click(), and the unrestricted invocation be allowed through policy or some user-defined permission. But that seems like a lot of effort to go through, just to maintain consistency with the markup based model.

If the application wants to take a picture, just calling an API directly seems the logical thing to do, rather than:
- create a markup element (hidden, most likely)
- invoke the element with .click()
- handle the event
- delete the element

The markup-based approach must certainly be more resource-intensive (all that DOM manipulation is not free), and in resource-constrained devices (e.g. mobile) that is a big deal. Of course I suppose the webapp could leave the clickable element in the document, but that probably represents another security threat. 

Best regards,
Bryan Sullivan | AT&T
-----Original Message-----
From: Arve Bersvendsen [mailto:arveb@opera.com] 
Sent: Wednesday, December 02, 2009 9:22 AM
To: SULLIVAN, BRYAN L (ATTCINW); public-device-apis@w3.org
Subject: Re: <input type=photo> etc as Capture API

On Wed, 02 Dec 2009 18:10:10 +0100, SULLIVAN, BRYAN L (ATTCINW)  
<BS3131@att.com> wrote:

> Hi Arve,
> Re your responses to my comments:
>
> " a user agent can probably be configured to allow the synthetication of  
> said event.  I view this largely
> as an implementation detail, not as something subject for a spec."
> [bryan] how then do we ensure interoperability, if it's not in a spec?  
> Do I have to code my app for the specific implementation approach of the  
> web runtime? That would not be good.

Synthesizing the event (in practice, this involves invoking .click() on  
the element) is already covered by other specifications (DOM Level 2  
Events, HTML5, DOM3 Events).

You're not going to get "interoperability" on a capture API anyhow: On the  
open web, browser vendors are highly unlikely to allow unattended access  
to security-sensitive devices such as camera or microphone - just like  
they don't allow unattended access to the filesystem.

In the context of installed/installable web applications, where a trust  
decision has been made on a permanent basis, through some means, it is  
simply a matter of allowing synthetic clicks instead of not allowing them.

> " As for controlling which camera <input> would choose: I'm pretty sure  
> a microdata approach would easily solve this "
> [bryan] Again, how/where would we define the use of the microdata  
> normatively, to ensure interoperability?

The microdata approach would of course have to be specified.

-- 
Arve Bersvendsen

Opera Software ASA, http://www.opera.com/

Received on Wednesday, 2 December 2009 17:33:57 UTC