- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Sun, 09 Dec 2012 22:19:30 -0800
- To: public-device-apis@w3.org
- CC: Ms2ger <ms2ger@gmail.com>
On 12/07/2012 07:45 AM, Frederick.Hirsch@nokia.com wrote: > fantasai > > Much thanks for raising your Last Call comment on HTML Media Capture and actively following up on the DAP email list on the topic. > > The DAP Working Group has agreed to change the HTML Media Capture specification to make the capture attribute a boolean (thus relying only on accept MIME type to specify what is captured) and has also revised the specification with additional examples. > > See the latest editors draft for details: http://dev.w3.org/2009/dap/camera/ > > (there is also a diff, http://dev.w3.org/cvsweb/2009/dap/camera/Attic/unofficial.html.diff?r1=1.3;r2=1.4;f=h ) > > 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. 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.) 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. 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? ~fantasai
Received on Monday, 10 December 2012 06:22:08 UTC