Re: [capture] HTML Media Capture implementor's feedback

Hi Rich,

If the capture and accept attributes aren't compatible then Chrome for
Android will ignore the capture attribute. For example:

<input type=file accept="video/*" capture="camera">

Will result in a standard Android file picker filtered to only show file
sources that can provide video.

Thanks, Ben

On 11 May 2012 11:11, Rich Tibbett <richt@opera.com> wrote:

> Rich Tibbett wrote:
>
>> Ben Murdoch wrote:
>>
>>> Hi there,
>>>
>>> Chrome for Android uses the 'capture' attribute on a file input element
>>> to provide a hint that the user should be taken directly into the
>>> media acquisition application. For example, specifying capture="camera"
>>> will launch the camera app, "camcorder" the camcorder or "microphone"
>>> the sound recorder. Without the capture attribute, the user would be
>>> presented with a standard Android file picker, filtered on the 'accept'
>>> attribute if it's present.
>>>
>>> The Android Browser implements similar functionality but to an older
>>> version of the spec where the capture value was specified as a MIME type
>>> parameter on the 'accept' attribute.
>>>
>>> Hope this helps
>>>
>>
>> Yes, that is helpful. Thanks.
>>
>> I'm assuming that the MIME type parameter provided in an accept
>> attribute is overridden if it doesn't match the requested capture
>> attribute.
>>
>
> For clarity here...
>
> s/the MIME type parameter/the MIME type value/
>
>
>
>> i.e. <input type=file accept="video/*" capture="camera"> will still
>> trigger the camera directly and return an image file on completion (?)
>> or does it fail to launch the take any action (i.e. launching the
>> camera) (?) or fallback to the standard file picker functionality
>> (thereby ignoring the capture attribute) (?).
>>
>
> s/does it fail to launch the take any action/does it fail to launch or
> take any action/
>
>
>
>> We should document that UA behavior in the current spec [html-capture]
>> for consistency purposes IMO.
>>
>> Is there any other special behavior here we should document?
>>
>> - Rich
>>
>> [html-capture] http://dev.w3.org/2009/dap/**camera/<http://dev.w3.org/2009/dap/camera/>
>>
>>  Ben
>>>
>>> On 10 May 2012 23:28, Rich Tibbett <richt@opera.com
>>> <mailto:richt@opera.com>> wrote:
>>>
>>>
>>>
>>> On May 10, 2012, at 8:06 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>>
>>> > On Thu, May 10, 2012 at 3:55 AM, Anssi Kostiainen
>>> > <anssi.kostiainen@nokia.com <mailto:anssi.kostiainen@**nokia.com<anssi.kostiainen@nokia.com>
>>> >>
>>> wrote:
>>> >> Hi Jonas,
>>> >>
>>> >> On 10.5.2012, at 10.57, ext Jonas Sicking wrote:
>>> >>
>>> >>> What did they actually implement if they didn't implement the
>>> new IDL
>>> >>> interfaces?
>>> >>
>>> >> The capture attribute. I guess Adam meant to say that "we don't
>>> have any plans to implement the WebIDL interfaces" other than the
>>> following (Adam, correct me if I'm wrong):
>>> >>
>>> >> [Supplemental] interface HTMLInputElement {
>>> >> attribute DOMString capture;
>>> >> };
>>> >>
>>> >>> We've also implemented capture support for <input type=file> Mobile
>>> >>> Firefox (it's available in nightlies), but our support didn't
>>> use the
>>> >>> DAP spec at all, just plain HTML5 (or HTML4 even if you're just
>>> >>> submitting the picture using a <form>).
>>> >>
>>> >> And now we've got some more implementor's feedback, thanks
>>> Jonas! Keep it coming.
>>> >>
>>> >> Now I'd be especially interested in hearing your feedback re the
>>> capture attribute.
>>> >
>>> > What I'm saying is that we've implementation the functionality that
>>> > the capture attribute apparently intents to provide, without actually
>>> > using the capture attribute.
>>> >
>>> > I.e. on Firefox for Android if you simply put the markup <input
>>> > type=file> in a page, the user can choose to use the camera, gallery
>>> > application, voice recorder etc, to provide a picture, video or audio
>>> > file.
>>> >
>>> > We've observed the same functionality in Chrome for Android.
>>> >
>>> > So my question is, what does webkit do different if the capture
>>> > attribute is set to the various values defined by the spec, compared
>>> > to if it's not set?
>>> >
>>> > I.e. what have they actually done to "implement the capture
>>> attribute"?
>>>
>>> The native browser for Android does something similar but hangs the
>>> explicit request for e.g the camera off the accept attribute
>>> instead. I.e. <input type=file accept="video/*;capture=**camera">. The
>>> effect of this is best demonstrated in [1] (..despite the confusing
>>> post title). Maybe that was carried over to Chrome for Android.
>>> Either way some confirmation of this from someone working on Webkit
>>> would be helpful.
>>>
>>> In terms of actual benefit this really comes down to one less user
>>> click, less options for a user to choose each time, and invoking the
>>> camera directly if you are implementing e.g. Instagram in a web
>>> browser. If you want to implement a media uploader you'd probably
>>> stick with <input type=file>. If you want to implement a camera app,
>>> receiving camera-generated images only, you'd use the capture
>>> attribute (or the variation supported by the native browser on Android).
>>>
>>> Instagram in a web browser seems like a fairly solid use case to
>>> want this 'shortcut' to the camera to exist in the web platform.
>>>
>>> HTH, Rich
>>>
>>> [1]
>>> http://davidbcalhoun.com/2011/**android-3-0-honeycomb-is-**
>>> first-to-implement-the-device-**api<http://davidbcalhoun.com/2011/android-3-0-honeycomb-is-first-to-implement-the-device-api>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Google UK Limited
>>>
>>> Registered Office: Belgrave House, 76 Buckingham Palace Road, London
>>> SW1W 9TQ
>>> Registered in England Number: 3977902
>>>
>>>
>>>


-- 
Google UK Limited

Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W
9TQ
Registered in England Number: 3977902