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

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

Received on Thursday, 10 May 2012 22:28:55 UTC