W3C home > Mailing lists > Public > public-html@w3.org > August 2011

Re: HTML.next and Rechartering

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Fri, 12 Aug 2011 09:20:34 +1000
Message-ID: <CAHp8n2khVtLhQe6dvBTQCkYAh9wnwbjirdTAiJqr2nY7s7TwyQ@mail.gmail.com>
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.


Received on Thursday, 11 August 2011 23:21:21 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:16 UTC