Comments on: W3C Capture API our in draft

By: Aphrodisiac

Aphrodisiac — Fri, 15 Jan 2010 11:40:55 +0000

very intresting
thanks

By: robinberjon

robinberjon — Mon, 14 Dec 2009 09:45:53 +0000

A few things ought to be clarified here:

First, this draft is internal to the working group. Since we work in public, it happens to be available for everyone to read, but it is not an official release in any way — you are looking at what is very, very much work in progress and the final thing might look very different.

Second, there is ongoing debate about the right approach to take to this on the mailing list: http://lists.w3.org/Archives/Public/public-device-apis/

Finally, given that it’s public, comments from any reader here are very much welcome. Simply send them to the above list. Topics of particular interest include whether to use an approach based on the input element, and whether to tackle embedding a viewfinder with live video (or the audio equivalent) as part of v1.

By: richtaur

richtaur — Sat, 12 Dec 2009 09:06:32 +0000

@blister: “… a conforming implementation of this specification must provide a mechanism that protects the user’s privacy and this mechanism should ensure that such operations must be authenticated.” That’s good!

I’m fine with the multiple callbacks (very common in JS frameworks) but typically they are referenced from an Object argument, not in multiple arguments with a Number argument separating them, that’s odd.

In many JS frameworks it looks something like: call({success : fn, error : fn});

By: olalonde

olalonde — Sat, 12 Dec 2009 08:55:46 +0000

W3C Capture API ___our___ in draft. My eyes!!! On another note, I’ve been waiting for this draft for a long time. Will it be part of the HTML 5 specs?

By: NikitaVasilyev

NikitaVasilyev — Fri, 11 Dec 2009 20:55:28 +0000

I would like to see API for capturing screenshots.

By: chrisfjay

chrisfjay — Thu, 10 Dec 2009 23:00:45 +0000

Most of this API is a confused, conflicting rewrite of the W3C File API, which has just been implemented in Firefox. Instead of re-inventing the wheel with navigator.device.captureImage(), it should be an api on the HTML input element, which would allow you to use the proper W3C File API to examine the properties of the content you've created (and which is more semantic, and already has an attribute for mime-type). I would go for input.sensors.captureImage(), which would allow you to add additional sensors in future such as microphone, webcam, temperature, pressure etc.

By: vilcans

vilcans — Thu, 10 Dec 2009 08:19:25 +0000

It looks nice and simple, but limited. I don’t see how it could be used for anything realtime, like video chat (although that’s mentioned in the Use Cases section of the document). It doesn’t give access to audio data, so you can’t analyze frequencies or audio levels. I guess you can get access to image pixels by drawing the image on a canvas though.

The capture API seems to be designed mainly for mobile devices. It would be nice with an API with more capabilities for more powerful devices, so Javascript can compete better with Flash.

By: rdza

rdza — Thu, 10 Dec 2009 03:00:41 +0000

It’s be nice to have frequency and waveform data for captured audio like flash does, but I guess if the raw data is there we can generate (some of?) that info from js via Fourier.

By: millermedeiros

millermedeiros — Thu, 10 Dec 2009 00:34:22 +0000

I think it’s really strange to have 2 different callbacks.. (never seen it anywhere else) I think it would be better if it work like this:
navigator.device.captureImage(callbackFn, [limit]);
and callback always returning an object with the “status” property (success/error).
I think limit should also be optional and default to 1 (or maybe “infinite”).

By: antimatter15

antimatter15 — Wed, 09 Dec 2009 20:13:59 +0000

I was making a JS port of a optical-touch related project of mine ( http://shinytouch.googlecode.com ), and I used with to access the pixel data. I would have thought that it would have been something like a special URL like device://camera in the src field of a , but I guess that isn’t quite capable of everything that a device would need (like adjusting the camera resolution, focus, etc).

By: blister

blister — Wed, 09 Dec 2009 20:08:02 +0000

I like the API, though I want to make sure that the camera and microphone access is opt-in like it is with flash. Any application that requests access to the camera or microphone should automatically force the user to accept that access.

Is this written into the specification?

By: JW123

JW123 — Wed, 09 Dec 2009 17:58:09 +0000

Well, it looks like the “fluff” is just part of the example, so it can display the captured image in a DIV. You wouldn’t necessarily need that in a real-world situation.