probably the biggest open issue in how much of a mobile device's capabilities a web-based application can use was the lack of access to the camera. initiatives such as BONDI and PhoneGap had long recognized this and provided APIs for accessing the camera. as of today, there finally is a W3C draft addressing this issue, and it is intended for both camera (image and video) and audio capture.
while this is not in any way associated with HTML5 (the document was published by the Device APIs
and Policy Working Group), it makes sense to simply add this to the list of activities that try to turn the browser into a richer programming platform, and most people would probably summarize these activities under the
HTML5 label. this means that
The Capture API draft is yet another addition to the HTML5 API Overview, which therefore has been updated accordingly.
this first draft defines an API for capturing still images from a camera, but there currently is no support for continuous capture. for some reason, i am increasingly fascinated by the (so far largely ignored) possibilities of device-readable representations of URIs, for example QR codes. the most user-friendly QR capture programs all use continuous capture, where the capturing process is continuously searching for a code until it finds one or the user stops the input process. generally speaking, my take is that QR recognition should be an integral part of mobile device data input capabilities anyway, but since that is probably not going to happen anytime soon, it would be nice if web pages could support QR recognition via the camera API.
but maybe there is a third way: a browser API for QR recognition, where the web page would initiate the capture of a code, the browser would take over control until a code had been recognized or the process has been canceled, and the API would return the recognized text. the big advantage of this approach would be that code recognition could be done natively (in browser code) instead of as scripting code, which probably would make more sense given the non-trivial computing resources it takes to support a continuous QR code recognition process.
regardless of my personal obsession with QR codes, it is really good to see that the last huge gap of browser functionality now has been closed; it will be interesting to see who and when first implementations of the API will show up in browsers.