W3C home > Mailing lists > Public > public-device-apis@w3.org > June 2010

Re: Capture API question

From: Arun Ranganathan <arun@mozilla.com>
Date: Fri, 11 Jun 2010 11:29:39 -0700
Message-ID: <4C128093.6010404@mozilla.com>
To: Andrei Popescu <andreip@google.com>
CC: Dominique Hazael-Massieux <dom@w3.org>, public-device-apis@w3.org, Brad Lassey <blassey@mozilla.com>, Doug Turner <dougt@mozilla.com>, khuey@mozilla.com
On 6/11/10 3:21 AM, Andrei Popescu wrote:
> On Fri, Jun 11, 2010 at 10:48 AM, Dominique Hazael-Massieux<dom@w3.org>  wrote:
>> Le vendredi 11 juin 2010 à 10:41 +0100, Andrei Popescu a écrit :
>>>> That said, we're very much interested in getting feedback — in
>>>> particular from implementors — on whether these additional features are
>>>> needed/useful in a v1, or if focusing on the form-based approach is more
>>>> cost-effective.
>>> On Android we are only implementing the form-based approach for now.
>>> This seems to work pretty well for the majority of the use cases we've
>>> encountered.
>> Thanks, that's very useful to know; do you see a need for standardizing
>> anything addional about it, though? In other words:
>> * are you implementing or considering to implement the ViewFinder
>> interface, or are you only plugging access to the camera from the file
>> picker?
> No, we're not implementing the ViewFinder interface. We're just
> hooking the camera to the file picker. The only extension we're
> considering is to allow the author to invoke the camera directly using
> <input type="file" accept="image/*;source=camera">
> UAs that don't know what "source=camera" is will just pop up a regular
> file picker.

This is the basis for implementation in Firefox.  We'll work with the 
existing form element.  We intend to use the File API for manipulating 
stills, just as we would a selection from the file system.  We'll use 
the same HTML syntax that Andrei mentions above, but haven't considered 
the additional "source=camera" bit.

1. Essentially take a look at: 
2. We also intend to provide a path from Canvas to Blob: 

The Capture API doesn't provide essential guidance for image capture on 
the web, and we are at present not considering it.  In particular, I 
find that:

1. The Capture API as currently written provides methods that we are not 
interested in implementing (at least for now), notably details about 
*how* images and video are captured.  It doesn't seem to build on 
existing mechanisms for dealing with form-selected data.  Also:
2. The Capture API doesn't address integration with existing HTML 
elements.  It introduces an "unharnessed" API space, which I find 
troubling and cannot reconcile with how the web works.

>> *are you implementing an additional set of methods on top of the File
>> API for media objects?

I'd welcome discussion of a Camera API for the web, including 
integration with the DOM (Canvas, forms, etc.).

-- A*
> Not for now but we are considering exposing the properties of the
> captured media (e.g. dimensions, duration, encoding, etc) using a
> subtype of File, like MediaFile in your spec.
> Thanks,
> Andrei
Received on Friday, 11 June 2010 18:30:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:45:59 UTC