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: Anssi Kostiainen <anssi.kostiainen@nokia.com>
Date: Mon, 10 Dec 2012 16:18:53 +0200
Cc: <public-device-apis@w3.org>, Ms2ger <ms2ger@gmail.com>
Message-Id: <92FE3A07-75C1-4B8F-A3FD-BA0D507575A8@nokia.com>
To: ext fantasai <fantasai.lists@inkedblade.net>
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:




Thank you for the most excellent feedback!

Received on Monday, 10 December 2012 14:19:28 UTC

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