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

Re: [html media capture] proposed (new) resolution of your HTML Media Capture Last Call Comment (Please respond)

From: fantasai <fantasai.lists@inkedblade.net>
Date: Sun, 09 Dec 2012 22:19:30 -0800
Message-ID: <50C57EF2.5060404@inkedblade.net>
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?

Received on Monday, 10 December 2012 06:22:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:47 UTC