- 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