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

Re: [html-media-capture] capture vs. accept

From: Rich Tibbett <richt@opera.com>
Date: Fri, 27 Jul 2012 13:43:01 +0200
Message-ID: <50127EC5.2080705@opera.com>
To: public-device-apis@w3.org
fantasai wrote:
>> On 7/19/12 6:02 PM, "fantasai" <fantasai.lists@inkedblade.net> wrote:
>>
>>> Hi!
>>> I was wondering, how is 'capture' different from 'accept'? It seems
>>> to me
>>> the
>>> following are equivalent:
>>>
>>> capture accept
>>> ----------------------
>>> camera image/*
>>> camcorder video/*
>>> microphone audio/*
>>> filesystem */*
>>
>> No. accept="image/*" tells you nothing about the desired capture mode,
>> which could be either of camera or filesystem.
>
> So the distinction between the two is that using the 'capture' attribute
> indicates that a live capture is preferred?
>
> In that case, I suggest that the 'capture' attribute be a boolean,
> leaving the type-checking to the 'accept' attribute, which already
> serves this function.

What would happen in the following case (assuming accept and capture are 
independently optional)?

<input type=file capture>

It could be nice to be able to invoke the camcorder/camera/microphone 
directly without having to always specify an accept attribute. The 
accepted mime types for any input elements that don't have an accept 
attribute can be inferred from the capture attribute's value precisely 
because of the equivalence you mention above.

<input type=file capture=camcorder>

The implication here is that the returned file(s) will be of type 'video/*'.

>
> Not only would this avoid duplication, it also avoids conflicts like
>
> <input capture=microphone accept='image/*'>

I believe the spec does address this:

"The HTMLInputElement interface's accept attribute takes precedence over 
the capture attribute. That is, if the accept attribute's value is set 
to a MIME type that is not accepted in a defined capture state, the user 
agent must act as if there was no capture attribute."

- Rich
Received on Friday, 27 July 2012 11:43:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 July 2012 11:43:34 GMT