This document:Public document·View comments·Disposition of Comments·
Nearby:Device and Sensors Working Group Other specs in this tool
Status: allopen proposal pending resolved_yes resolved_no resolved_partial other Type: allsubstantive editorial typo question general comment undefined
Quick access to LC-2635 LC-2636 LC-2637 LC-2638 LC-2639 LC-2640 LC-2641 LC-2642 LC-2644
There are 9 comments (sorted by their types, and the section they are about).
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
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
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.
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.
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.
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.
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.
== 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).
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.
Add a comment.