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

On Thu, Jul 22, 2010 at 9:56 AM, Andrei Popescu <andreip@google.com> wrote:
> 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)?

I'm not a UI expert, so take what I say with a shovel of salt.

I suspect that images are far more common than anything else today, so
we could have just a button for that, and then allow easy switching
between camera/camcorder/microphone one you are in 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)
>>
>
> Yes but in my example the application controls the style and position
> of each of the buttons. This is what our Web app wanted.

Position I understand, but how do you control the style of the buttons
in your example? Can you show an example that for example makes the
background of the button green? Note that

<input type=file style="background: green">

does something else in at least current chrome builds.

>> 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 one extra click is all we're trying to avoid in this thread, no?

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

The final call isn't mine, but at least not for now now. But we will
make it easier for users to use cameras on millions of pages. IMHO
that's a bigger win.

/ Jonas

Received on Thursday, 22 July 2010 17:22:40 UTC