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

Hi Jonas,

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

To clarify, given the following markup:

<input type="file" accept="image/*">

the Android browser renders a single button on the page. When clicked,
this button brings up a native file picker that asks the user to
choose the source of the file: file system or camera. Once she makes
this choice, the user needs to select / capture the actual file.

However, we needed to support a use case where the Web application
wants to design their UI so that they have more control on how the
file picker starts up. They have markup similar to:

<input type="file" accept="image/*;capture=filesystem">
<input type="file" accept="image/*;capture=camera">

The user can then trigger the camera viewport or the media gallery
browser with a single click. The Web developers also style the above
buttons so that they fit nicely with the overall website look&feel,
etc. To support this use case, we came up with the 'capture'
parameter. We're totally open to better solutions :)

Thanks,
Andrei

Received on Thursday, 22 July 2010 11:13:06 UTC