W3C home > Mailing lists > Public > public-device-apis@w3.org > May 2012

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

From: Ben Murdoch <benm@google.com>
Date: Fri, 11 May 2012 10:45:38 +0100
Message-ID: <CAPHGM7W1L=Drby0Zt1Ddm9NEHAPu7RgFPj5hMw26tUVdrEMP-w@mail.gmail.com>
To: Rich Tibbett <richt@opera.com>
Cc: Jonas Sicking <jonas@sicking.cc>, Anssi Kostiainen <anssi.kostiainen@nokia.com>, Dominique Hazael-Massieux <dom@w3.org>, "public-device-apis@w3.org public-device-apis@w3.org" <public-device-apis@w3.org>, Ilkka Oksanen <Ilkka.Oksanen@nokia.com>, ext Adam Barth <abarth@webkit.org>, Andrei Popescu <andreip@google.com>
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

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
Registered in England Number: 3977902
Received on Friday, 11 May 2012 09:46:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:37 UTC