- 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
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 UTC