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

On Thu, Jul 22, 2010 at 5:26 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> 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?
>

Hmm, so if you leave out the accept parameter, will you render four
buttons (camera, filesystem, camcorder, microphone)?

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

Yes but in my example the application controls the style and position
of each of the buttons. This is what our Web app wanted.

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

But we do that already (with actually 4 choices), except that one
extra click is required: first click on the single <input> button in
the page, then click again in the resulting native file picker dialog
to select the source.

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

So you won't support the use case I mentioned since the app won't be
able to place the buttons in a way that suits their UI.

Thanks,
Andrei

Received on Thursday, 22 July 2010 16:56:43 UTC