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

On Wed, Jul 21, 2010 at 7:49 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> 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>?

For the above markup, it does exactly that.

> 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.
>

Agreed.

'capture' is for the new applications that want to control how the
file picker starts up, as I explained in my previous email.

All the best,
Andrei

Received on Wednesday, 21 July 2010 18:54:59 UTC