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: Mon, 3 May 2010 22:38:18 +0000 (UTC)
To: Nathan <nathan@webr3.org>
Cc: Fenton Travers <fenton_travers@yahoo.com>, Jock Murphy <jockm@stufflabs.com>, public-html-comments@w3.org
Message-ID: <Pine.LNX.4.64.1005032235360.8532@ps20323.dreamhostps.com>
On Mon, 3 May 2010, Nathan wrote:
> Ian Hickson wrote:
> > On Thu, 29 Apr 2010, Fenton Travers wrote:
> >> 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.
> 
> Could you expand on this a little - it's left me somewhat confused.
> 
> Is the takeaway that HTML5 will constantly be in flux and never reach 
> Recommendation / be a Web Standard?

I'm arguing that HTML (not HTML5, just HTML) should be in a state of 
constant improvement, with the stability of each part being tracked 
separate from the whole. This is effectively what's going on now at the 
WHATWG:

   http://whatwg.org/html


> Will there be (or is there) some form of core HTML5 specification that 
> vendors must implement and support, and then optional specifications 
> which vendors can choose to implement or not - or at least a structure 
> that would allow vendors to effectively say we "support a,b,c but not d 
> & e"?

Browser vendors are never forced to do anything. It's our job as spec 
writers to make sure that everything in the spec is what the browser 
vendors are willing to implement, and to remove what they don't want to 
implement. This is the case with the current process as well as with the 
process I'm suggesting we follow going forward.


> The short is, when I'm authoring a document I need to know what's 
> supported globally, or at least what should be supported globally.

The only way you can know that is to test it.


> aside: is there a fixed way of determining at runtime what features are 
> supported before attempting to use them (particularly with js related 
> features) or is it up to userland to figure out how?

It depends on the feature.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 3 May 2010 22:38:33 GMT

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