Re: HTML Media Capture draft from Device APIs and Policy Working Group

On Wed, Jul 21, 2010 at 7:18 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Wed, Jul 21, 2010 at 5:22 AM, Henri Sivonen <hsivonen@iki.fi> wrote:
>> On Jul 20, 2010, at 18:33, Dominique Hazael-Massieux wrote:
>>
>>> The Device APIs and Policy Working Group has published a new draft
>>> called "HTML Media Capture" on which we think we'll need to coordinate
>>> with your group:
>>> http://www.w3.org/TR/2010/WD-html-media-capture-20100720/
>>>
>>> That document defines a mechanism to bind an <input type=file> with a
>>> set of well-defined accept attribute values, completed by a mime type
>>> parameter ("capture"), with an extended file picker (that integrates
>>> access to on-device microphones, cameras and camcorder) and resulting in
>>> a MediaFile object that extends the File object from the FileAPI.
>>
>> Why is the capture parameter needed?
>>
>> Why wouldn't browsers always allow the use of a capturing device (in addition to picking an existing file) when a page has <input type=file accept='...'> where '...' is a capturable type and there's a suitable capture device available?
>
> A few comments:
>
> The MediaList interface is unnecessary. The Files returned from the
> FileList interface can implement the MediaFile. Compare to how
> NodeList interface always returns Node objects, but that those Node
> objects often also implement Element or TextNode.
>
> It's good that the 'capture' mime parameter is defined to be a hint
> and isn't required to affect behavior in any way. It's still unclear
> that it is really needed. A good browser UI should likely *always*
> display buttons for attaching a file or capturing a new image or video
> using a camera. That is what we are long term hoping to do for firefox
> since the vast majority of pages don't have an @accept attribute at
> all. If an implementation want to be conservative and not always
> display a button for capture, triggering off of @accept containing a
> "image/..." mimetype seems reasonable.
>

On Android, we needed to support the following use case: a Web page
wants to show two separate buttons:

1. a button that allows the user to pick a file from the device gallery
2. a button that directly invokes the camera viewfinder and allows the
user to capture a new file.

We achieved this with the 'capture' parameter, which acts as a hint to
the browser about the default startup mode of the file picker (i.e.
the camera viewfinder or the gallery browser). If capture is not
specified, you get the traditional file picker with all applicable
choices.

Thanks,
Andrei

Received on Wednesday, 21 July 2010 18:36:37 UTC