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

On Wed, Jul 21, 2010 at 11:36 AM, Andrei Popescu <andreip@google.com> wrote:
> 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.

Why doesn't android simply always show two buttons for <input
type=file name=X>? That is what I'd want as a user since there are
literally millions of pages out there that has that markup and where I
want to attach a picture using my camera.

/ Jonas

Received on Wednesday, 21 July 2010 18:50:24 UTC