W3C home > Mailing lists > Public > public-html-comments@w3.org > May 2010

Re: Can accessing the device microphone and camera be added to HTML5?

From: Ian Hickson <ian@hixie.ch>
Date: Sun, 2 May 2010 21:11:13 +0000 (UTC)
To: Fenton Travers <fenton_travers@yahoo.com>, Jock Murphy <jockm@stufflabs.com>
Cc: public-html-comments@w3.org
Message-ID: <Pine.LNX.4.64.1005022057430.8532@ps20323.dreamhostps.com>
On Thu, 29 Apr 2010, Fenton Travers wrote:
>
> Can accessing the device microphone and camera be added to HTML5?

HTML5 is frozen to new additions, but we're looking at adding device 
access to a future version of HTML:

   http://www.whatwg.org/specs/web-apps/current-work/multipage/commands.html#devices


On Sun, 2 May 2010, Jock Murphy wrote:
>
> Honestly I am personally amazed that HTML5 is still open.  I mean I am 
> just a slightly more than average observer, but to me this long period 
> of standard forming is part of the problem.

Standards are like software -- if you stop maintaining them, they die.


> If I had my druthers, I would like to see the spec frozen to new additions,

It is (with the exception of subtitles for <video>, which was 
intentionally delayed but which is considered too important to delay 
until a next version).


> spend a short but reasonable time resolving anything that needs to be
> resolved

That's what we're doing. How do you decide when to stop resolving bugs? 
Would you just leave problems in the spec unfixed after a bit?


> and then start work on HTML 5.1, or HTML 6, or HTML Codename Betty and 
> Veronica, or whatever it should be called next.

That's already started.


> Get into a 12-18 month cycle for spec upgrades for a while, until we run 
> out of major areas of improvement, then things can slow down again.

I think a better solution would be to have a continuous process of adding 
features and fixing bugs, with no frozen versions. What's the point of a 
cycle? It doesn't match any of the browser vendors, it doesn't match the 
authoring community, so why bother? It's just artificial.


>    - APIs for Capturing Audio, Video, and Stills

Already in HTML5 as <input type=file>. (Actually it was already in HTML4.) 
For streaming capture, <device> in a future version of HTML.


>    - Support for non mouse input (accelerometers, gestures, etc)

That's out of scope for HTML; it's something to bring up in the Web Apps 
working group for DOM Events (www-dom@w3.org).


>    - The idea of a sandboxed file store, and the ability to work with files
>    (I would love to be able to know the modification date of the file I may be
>    uploading, or working with locally, as an example)

This is being specified by the Web Apps and Device APIs working groups.


>    - The ability to send and receive data over bluetooth obex, or other
>    means

This was in a past version of HTML5, but was removed due to lack of 
implementor interest.


>    - The ability to access nonfile like things (the address book for example

Why does this need anything from the browser?


>    - A more Java like sandbox that users can control what rights a webapp
>    might have

Already in HTML5 as <iframe sandbox>.


> But unless one of the major browser vendors implement these things and 
> then get them retrospectively added to the spec, I don't personally 
> think any of these will get added any time soon.

Many of these are already being implemented.


> Instead HTML5 will dither on for however long it is going to take for 
> them to decide to stop taking submissions (when was the last reasonably 
> likely one BTW?), then formalize the spec, and then decide to move 
> forward.

We're way past that stage.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Sunday, 2 May 2010 21:11:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 1 June 2011 00:14:02 GMT