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

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/
>
>> 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:11:55 UTC