- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Fri, 12 Aug 2011 09:20:34 +1000
- To: Sam Ruby <rubys@intertwingly.net>
- Cc: public-html@w3.org
On Fri, Aug 12, 2011 at 9:07 AM, Sam Ruby <rubys@intertwingly.net> wrote: > On 08/11/2011 06:21 PM, Silvia Pfeiffer wrote: >> >> We could, for example, right now split out all those >> features that are stable > > Again, I encourage you to make specific proposals, starting with bug > reports. > >> So, while I sympathize with the spirit of the W3C process, I think our >> execution of it is rather unsatisfactory and I feel unable to make an >> informed decision on whether the HTML specification in its >> completeness should actually move forward in the maturity or not. I >> want it to move forward, but at the same time I want to really hold >> back on large parts of it. This is why I'm not able to vote on such a >> decision. > > In the short term, nothing will change unless people start making concrete > proposals as to what they want to see taken out of the document. The maturity indicators that the WHATWG spec applies to the different features would be a good starting point to separate out the spec. The only person that is really able to make this split out of "stable" vs "unstable" features is the editor. Once a "stable" document has been created and agreed on, it would be easier to identify features that should be focused on next. So, in a first step, a "CR"-ready branch could be created with just the features that are implemented in a cross-browser ready manner. Then the rest of the spec can be regarded as at "WD" stage. And a new branch could be create with all the new stuff which you call HTML.next. > That being said, in the long term what you are describing is exactly what > will happen as features for which we can't demeonstrate interoperability > will have to be jettisoned later in the process. > > So: you can be a part of the process and help things along; or you can > simply wait and we will end up in the same place anyway. We just will get > there sooner (and with a lot less wasted effort) if people like you identify > what parts should be effectively held back -- I say this as removal from > HTML5 will not make such features ineligible for inclusion in HTML.next. This is where it becomes problematic: if you call the next version of HTML "HTML5", then you can't release it as a complete spec unless you have many of the still immature features ready. For example, I would say that the multitrack specification part of HTML5 video is still very immature and should not move to "CR". But we cannot take it out of HTML5 because it satisfies some core requirements for HTML5 video accessibility. So, we could have a HTML5v1 with all the stable features right now with the implication that there are important features without with HTML5 is incomplete, but they are not mature enough yet. HTH. Cheers, Silvia.
Received on Thursday, 11 August 2011 23:21:21 UTC