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: Tobie Langel <tobie@fb.com>
Date: Wed, 13 Jun 2012 10:34:48 +0000
To: Anssi Kostiainen <anssi.kostiainen@nokia.com>
CC: "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-ID: <CBFE3171.8D81B%tobie@fb.com>
Hi Anssi,

Thanks for the feedback.

On 6/13/12 9:39 AM, "Anssi Kostiainen" <anssi.kostiainen@nokia.com> wrote:

>Hi Tobie, All,
>On 12.6.2012, at 14.56, ext Tobie Langel wrote:
>> In [HTML Media Capture], section 5.1 Attributes, it is stated that "The
>> capture attribute is used as a hint to the user agent to invoke a file
>> picker of a specific capture control type."
>> I searched through the mailing list's archives and couldn't find an
>> explanation of why a more binding requirement wasn't picked instead (RFC
>> 2119, SHOULD comes to mind).
>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."

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.

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.


Received on Wednesday, 13 June 2012 10:35:22 UTC

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