- From: Anssi Kostiainen <anssi.kostiainen@nokia.com>
- Date: Mon, 10 Dec 2012 16:18:53 +0200
- To: ext fantasai <fantasai.lists@inkedblade.net>
- Cc: <public-device-apis@w3.org>, Ms2ger <ms2ger@gmail.com>
Hi fantasai,
On 10.12.2012, at 8.19, ext fantasai wrote:
> On 12/07/2012 07:45 AM, Frederick.Hirsch@nokia.com wrote:
[...]
>> Does this latest change address your Last Call Comment LC-2642, "how is capture different from accept"?
>
> Yes, this change addresses my comment.
>
> However, I think the resulting spec is unclear about what the 'capture'
> attribute is intended to do. For example, the introductory paragraph:
>
> # The HTML Media Capture specification enables web page authors
> # to declaratively specify the upload of audio, video and still
> # images by adding a new attribute to the HTML input element.
> # This enables simplified capture using device capture device
> # supporting a variety of scenarios.
>
> is very vague. It seems to imply that without the capture attribute,
> audio, video, and still images cannot be uploaded. But they can.
> Uploading such files from the filesystem works just fine.
Good points. I updated the ED and rephrased Abstract and Introduction sections. Let me know if they're better now.
> 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.
]]
> Nothing in the normative prose of the spec sets up the expectation
> that an <input> with capture is intended to capture "live" media
> as a preference. Since my understanding is that this is the whole
> point of the spec, that seems like a failing in the normative prose.
Does "directly" help here?
[[
The capture attribute is a boolean attribute that, if specified, indicates that the capture of media directly from a media capture mechanism is preferred.
]]
Let me know what would be the preferred language. Technically speaking, the media captured is not "live".
> 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.
The updated ED:
http://dev.w3.org/2009/dap/camera/
Diff:
http://dev.w3.org/cvsweb/2009/dap/camera/Overview.html.diff?r1=1.141;r2=1.142;f=h
Thank you for the most excellent feedback!
-Anssi
Received on Monday, 10 December 2012 14:19:28 UTC