W3C home > Mailing lists > Public > public-device-apis@w3.org > March 2010

Re: ACTION-74: Propose options to move forward with Capture

From: Ilkka Oksanen <Ilkka.Oksanen@nokia.com>
Date: Tue, 16 Mar 2010 01:15:11 +0200
Message-ID: <4B9EBF7F.6010200@nokia.com>
To: ext Robin Berjon <robin@robineko.com>
CC: "public-device-apis@w3.org" <public-device-apis@w3.org>
Hello all,

The Capture API has now been updated to reflect Robin's two proposals. 
Additionally introduced is new options parameter.


This update comes very late but I hope it's still useful for the Capture 
API session in Prague.


On 13.01.10 15:52, ext Robin Berjon wrote:
> The three levels that I have in mind are:
>  Snapshot capture, external view/sound finder
>    This is essentially what could already be done today (has been done in at least Opera Mini): you click a file input button and instead of just a file picker you can also take a picture, or record AV content.
>    In trusted runtimes, you can synthesise the click even to get the same result (using jQuery, $("<input type=file accept=image/*").bind("change", sucCB).click() is all you ought to need).
>    It may be useful to capture this in a (probably non-normative, except perhaps for what to do in trusted cases) document, to clarify the topic and possibly plug some holes.
>  Snapshot capture, embeddable view/sound finder
>    As has been discussed earlier, this requires a simple API addition to the existing<input>  apparatus. A possible proposal for this has been described at http://www.w3.org/mid/165A9ED1-009D-4EDB-AA7D-689B2326DB92@robineko.com. This proposal can be refined to include some desirable aspects that have been requested (such as controlling the likes of zoom, aperture, etc.).
>    This would require a normative specification, but it shouldn't need to be very complicated.
Received on Monday, 15 March 2010 23:20:47 UTC

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