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

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
Ben

On 10 May 2012 23:28, Rich Tibbett <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> 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
>
>
>


-- 
Google UK Limited

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