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: Thu, 14 Jun 2012 06:25:11 +0000
To: Anssi Kostiainen <anssi.kostiainen@nokia.com>
CC: "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-ID: <CBFF4E3A.8D99C%tobie@fb.com>
On 6/14/12 7:49 AM, "Anssi Kostiainen" <anssi.kostiainen@nokia.com> wrote:

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

Absolutely. I read the accept attribute as the "what" and the capture
attribute as an the "how".

That said, the HTML5 specs hints at ways the picker can be customized
depending on the accept attribute. So for example: an accept attribute of
"image/*" could trigger a UI which offers the options of picking an image
from the photo gallery or take a picture using the device's camera. In
contrast, if the capture attribute is set to "camera", I would expect the
UI to be similar to the device's native camera application (which is NOT
to say it couldn't also offer the possibility for the user to instead pick
an existing photo from the photo gallery).

>> There are a lot of implementations of HTML Media Capture popping up
>> 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?

Unfortunately not at this time. I've filed a bug against Mozilla's
implementation, however:

Received on Thursday, 14 June 2012 06:28:15 UTC

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