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

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

But if android displays two buttons, then the user gets to control how
the picker starts up, which is even better, no?

/ Jonas

Received on Wednesday, 21 July 2010 21:18:58 UTC