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.
|Commentor||Comment||Working Group decision||Commentor reply|
|LC-2641 <a href='mailto:email@example.com'>Chaals McCathieNevile </a> (archived comment)||
||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.
|LC-2637 <a href='mailto:firstname.lastname@example.org'>Doug Schepers </a> (archived comment)||
||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.
|LC-2635 <a href='mailto:email@example.com'>Michael Cooper </a> (archived comment)||
||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."
|LC-2636 <a href='mailto:firstname.lastname@example.org'>Michael Cooper </a> (archived comment)||
||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."
|LC-2640 <a href='mailto:email@example.com'>Chaals McCathieNevile </a> (archived comment)||
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.
|LC-2638 <a href='mailto:firstname.lastname@example.org'>Doug Schepers </a> (archived comment)||
||Added examples of a video and audio capture to specification, see http://dev.w3.org/2009/dap/camera/#examples||yes|
|LC-2639 <a href='mailto:email@example.com'>Doug Schepers </a> (archived comment)||
||No change in order to maintain consistency with Android 4.0 browser and Chrome for Android.||yes|
|LC-2642 <a href='mailto:firstname.lastname@example.org'>fantasai </a> (archived comment)||
||No changes to the specification are needed, please see http://www.w3.org/mid/50127EC5.email@example.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
|LC-2644 <a href='mailto:firstname.lastname@example.org'>NN Murthy </a> (archived comment)||
||Changing capture attribute to boolean resolves issue.||yes|