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

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.

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) (?).

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/

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

Received on Friday, 11 May 2012 10:15:09 UTC