This document:Public document·Annotated document·View comments·Search comments·Add a new comment·Send replies to comments·Disposition of Comments·
Nearby:Device and Sensors Working Group
Other specs in this tool
Quick access to LC-2635
There are 9 comments (sorted by their types, and the section they are about).
I was wondering, how is 'capture' different from 'accept'? It seems to me the
following are equivalent:
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
N N Murthy
Why 'camcorder' instead of 'videocamera'? I think 'videocamera' would be
more intuitive for non-native speakers.
I like the example of camera access; I think that makes usage clear to
I would like also like to see an example of microphone access, and an
example of camcorder+audio input.
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
* The specification should make explicit statements about security
expectations, e.g., requesting permission before turning the
microphone on in order to capture from it.
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
== Video and Audio ==
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).
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.
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.
Add a comment.