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

Re: [capture] A couple of editorial comments

From: Tobie Langel <tobie@fb.com>
Date: Tue, 27 Nov 2012 20:28:39 +0000
To: "Frederick.Hirsch@nokia.com" <Frederick.Hirsch@nokia.com>
CC: "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-ID: <F9981AFB970564408FEB7DFCF62D4408436B7F2D@SC-MBX01-4.TheFacebook.com>
Thanks for your answers, Frederick.

On 11/27/12 8:21 PM, "Frederick.Hirsch@nokia.com"
<Frederick.Hirsch@nokia.com> wrote:

>On Nov 21, 2012, at 7:38 AM, ext Tobie Langel wrote:
>> - The wording in the abstract seems to imply HTML Media Capture is only
>> useful to immediately upload captured content. It might be worth
>> mentioning it gives the document access to the capture content through
>> File API which allows client-side manipulation and storing (in
>The primary purpose is to upload immediately captured content. Why not
>use the FileAPI directly otherwise?

How can the FileAPI launch capture control types?

The use case is to take a picture, then manipulate and store it locally.

>That said, we should not make changes which lose the primary purpose
>though we could clarify that file upload is also possible
>> - I am not sure I fully understand the sentence "These form extensions
>> enable the upload of still images, video, and audio directly from a
>> capture mechanism but capture the default offered by the device,
>> limited control over what is captured."
>What is not clear? It says that using forms one can upload material
>captured by device mechanisms but cannot have fine grained control like
>handling tracks etc.

It is unclear to me whether the limited control refers to that of the end
user or the author. I'm also not sure what "the default offered by the
device" means in that context. (Not trolling, I really don't understand.
:-/ )


Received on Tuesday, 27 November 2012 20:29:18 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:56 UTC