- From: Nathan <nathan@webr3.org>
- Date: Mon, 03 May 2010 15:12:30 +0100
- To: Ian Hickson <ian@hixie.ch>
- CC: Fenton Travers <fenton_travers@yahoo.com>, Jock Murphy <jockm@stufflabs.com>, public-html-comments@w3.org
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? 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"? Surely there has to be core subset of everything under the HTML5 banner that vendors must/should implement - or is the authoring community to assume that what they create may not be fully supported? 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. 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? Best, Nathan
Received on Monday, 3 May 2010 14:13:10 UTC