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

Re: [MEDIACAPTURE] Why is the capture attribute merely a hint for the UA?

From: Anssi Kostiainen <anssi.kostiainen@nokia.com>
Date: Thu, 14 Jun 2012 08:49:54 +0300
Cc: "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-Id: <2C5826C8-7A19-4311-A4C3-399ACC51CA4E@nokia.com>
To: ext Tobie Langel <tobie@fb.com>
Hi Tobie, All,

On 13.6.2012, at 13.34, ext Tobie Langel wrote:

> On 6/13/12 9:39 AM, "Anssi Kostiainen" <anssi.kostiainen@nokia.com> wrote:
>> The intended behavior is similar to that of the accept attribute
>> [accept]. To align more closely with that language, we could change the
>> sentence to:
>> [[
>> The capture attribute MAY be specified to provide user agents with a hint
>> of a preferred capture control type for a file picker.
>> ]]
> Looks like my initial comment wasn't clear. Sorry about that. Let me try
> to rephrase it.
> Here's my suggested changes to the text:
>    "When the capture attribute is specified, the user agent SHOULD invoke
> a file picker of the specific capture control type."

That sounds fine as well.

All - WDYT?

> There is no point in adding a capture attribute if doesn't do more than
> **hint** to the UA that it should pick a less generic file-picker. As you
> mentioned, the accept attribute already does that. The capture attribute
> should be more binding, hence using SHOULD.

The accept and capture attributes are subtly different. Using the accept attribute you can, for example, give a hint that "I want an image only" whereas with the capture attribute you can additionally say "I want an image captured using a local camera on the spot".  The accept can act as a fallback to the capture attribute, thus they're likely to be used in tandem.

Traditionally web specs have left UI-related bits as implementation details. The spec as it is written now gives implementors more freedom to innovate on the UI.

> There are a lot of implementations of HTML Media Capture popping up these
> days and none of the ones I tested are using the value of the capture
> attribute to bypass a more generic file picker. I'm hoping clearer, more
> binding text in the spec would help with that.

Are you able to share your test results?

I think it'd be also helpful to understand implementors' point of view i.e. why they have chosen a specific implementation strategy. If any of the implementors are lurking on the list, please speak up :)

Received on Thursday, 14 June 2012 05:50:30 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:54 UTC