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

Re: [capture] making capture attribute boolean, the first stab

From: <Frederick.Hirsch@nokia.com>
Date: Wed, 5 Dec 2012 14:42:29 +0000
To: <anssi.kostiainen@nokia.com>
CC: <Frederick.Hirsch@nokia.com>, <public-device-apis@w3.org>
Message-ID: <1CB2E0B458B211478C85E11A404A2B2701845420@008-AM1MPN1-034.mgdnok.nokia.com>

Thanks, in general it looks to me personally  like this revision clears up a number of issues and is a step in a  very good direction. Thanks to those who have been persistently suggesting changes, and thanks for making an unofficial draft and diff, that makes it clear.

I have a couple of suggestions:

(1) Introduction

change "This enables unified capture and upload from the device capture device without requiring a user to save a file and then upload it in separate steps."


"This enables simplified capture using device capture device supporting a variety of scenarios."


" The capture attribute enables content authors to indicate the media to be captured and uploaded. Conformant user agents provide their users a more seamless access to the above-mentioned media capture capabilities of the hosting device."


"The capture boolean attribute allows authors to directly request use of the device capture mechanism."

(2) 5.1 has the statement

"When the capture attribute is specified, the user agent should invoke a file picker of the specific capture control type."

Is "invoke a device capture mechanism directly for the specific accept type"  clearer?

(3) Also in 5.1, I don't think precedence is relevant any more - perhaps change

"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 has no associated capture control type, the user agent must act as if there was no capture attribute."


"If the device has no device capture mechanism corresponding to the accept attribute then the user agent must act as if no capture boolean attribute were present, that is as if it were false."

(4) Is the Note in 5.1 still needed? Perhaps not.

(5) where are the accept and capture  attributes in example 5, 6,7?  Not sure how this invokes the built-in camera, for example. Examples probably should be media capture not file specific?


regards, Frederick

Frederick Hirsch

On Nov 29, 2012, at 10:46 AM, ext Anssi Kostiainen wrote:

> Hi,
> As per my ACTION-595, and as discussed on the yesterday's call, I started to look at how the HTML Media Capture spec might look like -- and what the implications might be -- if we'd make the capture attribute a boolean instead of an enumerated attribute.
> The short rationale is that we don't want to duplicate the information that is already expressed with the accept attribute. Also, given the feature is not yet widely deployed, we can probably still change things for better.
> I started writing the proposal in a mail first, but quickly found out it would be easier for everyone if I make an unofficial draft instead so that you'll get a proper diff etc.
> So I branched the spec, and reworked it. I also added new examples that should clarify how the revised spec would actually be used in both simple declarative-only scenario based on an HTML form, and in more advanced use cases involving scripting, such as upload via XHR, or drawing the captured image to a canvas on the client-side. I also wanted to clarify that uploading of the file is optional and that this feature is useful in client-side only scenarios too.
> The "new" unofficial version with a boolean capture is at: 
>  http://dev.w3.org/2009/dap/camera/unofficial.html
> The "old" Editor's Draft with an enumerated attribute is at:
>  http://dev.w3.org/2009/dap/camera/
> The diff:
>  http://dev.w3.org/cvsweb/2009/dap/camera/unofficial.html.diff?r1=1.1;r2=1.2;f=h
> That said, I'm looking for feedback whether we should go the boolean route. Also suggestions how to make the boolean spec better are welcome. There are probably some rough edges as I drafted this one rather quickly.
> -Anssi
Received on Wednesday, 5 December 2012 14:43:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:47 UTC