W3C home > Mailing lists > Public > public-device-apis@w3.org > September 2012

Re: [html-media-capture] HTML Media Capture Last Call Comments

From: Anssi Kostiainen <anssi.kostiainen@nokia.com>
Date: Thu, 6 Sep 2012 14:17:23 +0300
Message-Id: <76E933FF-F5EB-4C6D-9977-31FD60A8DA38@nokia.com>
To: "public-device-apis@w3.org public-device-apis@w3.org" <public-device-apis@w3.org>, "Hirsch Frederick (Nokia-CIC/Boston)" <Frederick.Hirsch@nokia.com>
Hi Frederick, All,

On 29.8.2012, at 16.27, Hirsch Frederick (Nokia-CIC/Boston) wrote:

> On Aug 23, 2012, at 7:57 AM, ext Anssi Kostiainen wrote:
>> 
>> On 15.8.2012, at 22.55, ext Frederick.Hirsch@nokia.com wrote:
>> 
>>> I have entered the Last Call comments on HTML Media Capture [1] into the Last Call comment tracker tool, completing ACTION-562
>>> 
>>> For the list see https://www.w3.org/2006/02/lc-comments-tracker/43696/WD-html-media-capture-20120712/
>> 
>> Thanks for populating the LC tracker! I assume we can address these comments on this thread, and when everyone's happy transfer the resolutions to the tracker.
> 
> fjh: you are welcome. I'll also take the action to put the responses in tracker and send the formal responses for issue resolution, once we discuss on today's call

Thanks, that'd be great!

[...]

>>> 2 how to integrate images from alternative devices like scanners, print readers etc. Clarify if such requirements met. LC-2644  ( https://www.w3.org/2006/02/lc-comments-tracker/43696/WD-html-media-capture-20120712/2644 )
>> 
>> Robin articulated the scope of the spec nicely in his reply:
>> 
>> http://www.w3.org/mid/8C34414C-F217-43AA-9B57-B41DB996711E@berjon.com
>> 
>> I believe we do not need to mention in the spec that revising the spec with additional inputs is possible, given that's the standard operating procedure of any lively web specification.
> 
> fjh: I assume we should include in the response that once we enter CR this means changes would have to be in a subsequent version of the spec unless we want to cycle back to LC. Do we have a use case now?

I haven't seen any use cases. Your proposal looks good to me.

[...]

>> Re camcorder+audio. 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.
>> 
>> If someone has a concrete proposal how to improve the prose, please let us know. Currently, the normative prose is as follows:
>> 
>> [[
>> 
>> 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.
>> 
>> ]]
>> 
>> Doug also mentions a potential use case for video-only capture:
>> 
>> [[
>> 
>> 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).
>> 
>> ]]
>> 
>> I'd leave this up to the UA to be handled within the video camera control (the camera UI could have e.g. a "make silent / mute" control and a microphone selection control).
> 
> fjh: perhaps you can add to the example section some of Doug's text along with the explanation you give here?

I added two extra bullets to the Security and privacy considerations section. I believe this would fit better there:

[[

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.

]]

I'm open to suggestions how to word this more clearly.

[...]

>>> 9 Specify that capture attribute can be in markup, not just script LC-2640  ( https://www.w3.org/2006/02/lc-comments-tracker/43696/WD-html-media-capture-20120712/2640 )
>> 
>> The specification extends the input element's File Upload state, which is defined in HTML5. In order to be consistent with the HTML5 spec, this spec also specifies the extensions in terms of the DOM. Here's the relevant HTML5 reference:
>> 
>> [[
>> 
>> Since DOM trees are used as the way to represent HTML documents when they are processed and presented by implementations (especially interactive implementations like Web browsers), this specification is mostly phrased in terms of DOM trees, instead of the markup described above.
>> 
>> http://dev.w3.org/html5/spec/introduction.html#a-quick-introduction-to-html
>> 
>> ]]
> 
> fjh: I think we should add some text to the draft to address this comment in a more explicit manner - i.e. state clearly that there can be markup - maybe add an example?

All the examples are in markup, which should address this concern. I would not change the normative prose in order to stay in sync with the HTML5 spec.

[...]

The Editor's Draft has been updated:

 http://dev.w3.org/2009/dap/camera/

The diff:

 http://dev.w3.org/cvsweb/2009/dap/camera/Overview.html.diff?r1=1.133;r2=1.134;f=h

I believe the working group has now addressed all the LC comments, and the next step is to enter the responses to the tool. Let me know if you need help with that.

Thanks for your comments!

-Anssi

[1]  http://www.w3.org/TR/2012/WD-html-media-capture-20120712/
Received on Thursday, 6 September 2012 11:17:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 6 September 2012 11:17:30 GMT