- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Mon, 10 Dec 2012 16:14:12 -0800
- To: Anssi Kostiainen <anssi.kostiainen@nokia.com>
- CC: public-device-apis@w3.org, Ms2ger <ms2ger@gmail.com>
On 12/10/2012 06:18 AM, Anssi Kostiainen wrote:
>
> I updated the ED and rephrased Abstract and Introduction sections. Let me know if they're better now.
Yes, they're better now. Thanks. :)
>> The term "device capture mechanism" appears as a distinguishing
>> feature of <input> with a capture attribute, but it's not clear
>> what such a thing is; it's not defined anywhere, not even by
>> example ("such as a camera or microphone").
>> # The capture boolean attribute allows authors to directly
>> # request use of the device capture mechanism.
>> (The use of 'the' here also implies that a device only has one
>> such mechanism.)
...
> I renamed the term "device capture mechanism" to "media capture mechanism"
> globally and defined it in Terminology section as follows:
# The term media capture mechanism refers to a device's local media
# capture device, such as a camera or microphone.
> Does "directly" help here?
Not much, no.
> Let me know what would be the preferred language. Technically speaking,
> the media captured is not "live".
Fair enough, but the intention is to capture it directly from the
device's environment, rather than directly from its memory. Right?
>> Lastly, I wanted to check that, if you plan to extend the 'capture'
>> attribute in the future to determine which of multiple appropriate
>> devices to use (e.g. switching it to an enumeration), is the WebIDL
>> for it able to accommodate such an extension? Or does the type need
>> to be DOMString instead?
>
> I think we do not have such extension plans at this time.
Indeed. But were you to have such a plan in the future (which, from
the discussions here, seems possible), would adopting the current
WebIDL prevent such an extension?
~fantasai
Received on Tuesday, 11 December 2012 00:14:46 UTC