W3C

Disposition of comments for the Device APIs Working Group

Single page view

In the table below, red is in the WG decision column indicates that the Working Group didn't agree with the comment, green indicates that a it agreed with it, and yellow reflects an in-between situation.

In the "Commentor reply" column, red indicates the commenter objected to the WG resolution, green indicates approval, and yellow means the commenter didn't respond to the request for feedback.

CommentorCommentWorking Group decisionCommentor reply
LC-2641 Chaals McCathieNevile <w3b@chaals.com> (archived comment)
2. Many devices have more than one camera. Although it makes no sense to
insist on a given one (some systems, like super-fancy video conferencing
systems that used to be science fiction and are now feasible to construct
from spare parts, have a lot of cameras), The fact that in a huge number
of cases you can divide them into "facing the user" and "the rest",
suggests that it would be nice to at least allow the simple hint as an
author request.
We changed the meaning of the capture attribute - it is now a boolean ( thus there are no keywords defined with it). The accept attribute defines the requested MIME type and if present the capture attribute indicates to use the device built-in capture mechanism to obtain content of that MIME type. Thus that mechanism could have a user interaction to determine which device, but that would be implementation dependent. I could also envision different MIME types for different camera choices (though maybe that would probably require standardization elsewhere).

Given the wide range of possible accept content types, it probably does not make sense for the HTML Media Capture specification to define capture choices at the device (and the current specification does not provide a means to do so).

The latest set of changes make this issue is moot since Keywords previously implied finer granularity but are no longer specified.

http://lists.w3.org/Archives/Public/public-device-apis/2012Dec/0022.html
yes
LC-2637 Doug Schepers <schepers@w3.org> (archived comment)
== Video and Audio ==
http://www.w3.org/TR/2012/WD-html-media-capture-20120712/#attributes

The 'camcorder' keyword value may conflate video and audio; I can
credibly see a use-case for video-only capture, and user expectation may
be ambiguous if that's not called out explicitly when they are selecting
their input (e.g. they may be unpleasantly surprised when they accept a
video source and their audio is also captured).

The user may also wish to select a different microphone input than is
bundled with the videocamera.

I suggest that the value of @capture should be a list of strings, not
just a single value, i.e.
<input type="file" accept="image/*" capture="camcorder,microphone">

This may result in a pair of source selections, sequentially selecting
first the videocamera input, then the microphone input (or, depending on
the UA and device, might have both in the same dialog... either way, it
should be explicit).
No change needed:

The accept attribute takes precedence over the capture attribute as per the spec. This means camcorder+audio would be the same as no capture attribute is present if the implementation's video camera control is unable to capture audio only. If the implementation's video camera control is able to capture audio only (in addition to video), then camcorder+audio and microphone+audio would yield similar results i.e. an audio file.

http://lists.w3.org/Archives/Public/public-device-apis/2012Aug/0101.html
yes
LC-2635 Michael Cooper <cooper@w3.org> (archived comment)
The Protocols and Formats Working Group took a quick look at the HTML Media Capture specification http://www.w3.org/TR/2012/WD-html-media-capture-20120712/. In a teleconference discussion, minuted at https://www.w3.org/2012/07/18-pf-minutes.html, we had the following comments:

What happens if the requested device is not present on the system? People with disabilities may have a different sub-set of devices available than mainstream users. We suggest the specification state explicitly that the user agent should fall back to a standard file upload widget in this situation.
No change needed, addressed by the following normative prose:

"The capture attribute's invalid value default and missing value default is the File Upload state."
yes
LC-2636 Michael Cooper <cooper@w3.org> (archived comment)
The Protocols and Formats Working Group took a quick look at the HTML
Media Capture specification
http://www.w3.org/TR/2012/WD-html-media-capture-20120712/. In a
teleconference discussion, minuted at
https://www.w3.org/2012/07/18-pf-minutes.html, we had the following
comments:

* The specification should make explicit statements about security
expectations, e.g., requesting permission before turning the
microphone on in order to capture from it.
Text added to to the Security and Privacy Considerations section

"The user agent should not enable any device for media capture, such as a microphone or camera, until a user interaction giving implicit consent is completed. A user agent should also provide an indication when such an input device is enabled and make it possible to terminate such capture. Similarly, the user agent should allow the user:

* to select the exact media capture device to be used if there exists multiple devices of the same type (e.g. a front-facing camera in addition to a primary camera).
* to disable sound capture when in the video capture mode."

see http://dev.w3.org/2009/dap/camera/#security

diff http://dev.w3.org/cvsweb/2009/dap/camera/Overview.html.diff?r1=1.133;r2=1.134;f=h
yes
LC-2640 Chaals McCathieNevile <w3b@chaals.com> (archived comment)
Editorial...
1. That the capture attribute in HTML can be added in markup (rather than
being added as a DOM attribute in script) is not obvious from the text,
but only from the example section. It would be helpful to clarify this.
http://lists.w3.org/Archives/Public/public-device-apis/2012Dec/0022.html

We addressed this in a number of places (for formatted version of quoted text see draft link below):

Introduction: "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."

Terminology: "The input element, HTMLInputElement interface, accept attribute, and File Upload state are defined in [HTML5]."

This indicates that input is an HTML element.

Examples: Examples 1,2,3 show declarative form without requiring Javascript; example 4 shows use of markup without form and examples 5-7 show how this can be processed.

http://dev.w3.org/2009/dap/camera/
yes
LC-2638 Doug Schepers <schepers@w3.org> (archived comment)
http://www.w3.org/TR/2012/WD-html-media-capture-20120712/#examples

I like the example of camera access; I think that makes usage clear to
developers.

I would like also like to see an example of microphone access, and an
example of camcorder+audio input.
Added examples of a video and audio capture to specification, see http://dev.w3.org/2009/dap/camera/#examples yes
LC-2639 Doug Schepers <schepers@w3.org> (archived comment)
http://www.w3.org/TR/2012/WD-html-media-capture-20120712/#attributes

Why 'camcorder' instead of 'videocamera'? I think 'videocamera' would be
more intuitive for non-native speakers.
No change in order to maintain consistency with Android 4.0 browser and Chrome for Android. yes
LC-2642 fantasai <fantasai.lists@inkedblade.net> (archived comment)
Hi!
I was wondering, how is 'capture' different from 'accept'? It seems to me the
following are equivalent:

capture accept
----------------------
camera image/*
camcorder video/*
microphone audio/*
filesystem */*

~fantasai
No changes to the specification are needed, please see http://www.w3.org/mid/50127EC5.2080705@opera.com

[[

> Not only would this avoid duplication, it also avoids conflicts like
>
> <input capture=microphone accept='image/*'>

I believe the spec does address this:

"The HTMLInputElement interface's accept attribute takes precedence over
the capture attribute. That is, if the accept attribute's value is set
to a MIME type that is not accepted in a defined capture state, the user
agent must act as if there was no capture attribute."

]]

additional updates as part of resolution : http://lists.w3.org/Archives/Public/public-device-apis/2012Dec/0032.html
yes
LC-2644 NN Murthy <nn.murthy@cmcltd.com> (archived comment)
Dear all,

This is regarding the above publication. Images media type are captured by
computer applications, not only using cameras but also, using document
scanners. Another source of images are live scan devices for capturing
finger prints, palm prints, iris etc. Can the standard address these
requirements?


N N Murthy
Changing capture attribute to boolean resolves issue. yes

Developed and maintained by Dominique Hazaël-Massieux (dom@w3.org).
$Id: doc.php,v 1.36 2014-02-19 08:10:56 dom Exp $
Please send bug reports and request for enhancements to w3t-sys.org