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

On Thursday, July 22, 2010, Andrei Popescu <andreip@google.com> wrote:
> 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' iTo 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 :)

Well, I'll repeat my earlier suggestion since it seems better to me
and you didn't give a reason why it was not.

Why don't you make android display, for <input type=file
accept="image/*">, two buttons? One that says "browse..." and brings
up a filepicker, and one that says "camera" and brings up the capture
UI?

It's telling that the example markup you gave results in almost the
same thing bring displayed to the user. Actually, my proposal results
in slightly improved UI since only one text field next to the two
buttons. Your example results in two separate fields. (Usually file
controls display a button for selecting a file, and a text field for
displaying the name of the selected file)

You can even improve on my proposal. Display above two buttons for all
<input type=file>. That will enable users to use the camera to attach
a picture in literally millions of pages that exist on the web
already.

That is what we're hoping to do for firefox.

/ Jonas

Received on Thursday, 22 July 2010 16:26:52 UTC