Re: HTML.next and Rechartering

Hi Sam,

That poll asked a very difficult question that I didn't feel I could
answer with any confidence.

I believe there are indeed features in HTML that should be published
as "stable" and that could easily be published as a HTML5 spec, giving
application developers out there confidence that these features won't
change any more and that browser support them, because they are
implemented in all major browsers in a compatible manner.

However, there are also many features that are only in specification
state or still under discussion or implemented only in one browser.

I personally don't think that the "Last Call" stage means much,
actually. I believe that the "Recommendation" stage means a lot more.
I also believe that we have features that are ready for the
"Recommendation" stage, but others aren't ready for "Last Call" yet.

I would much prefer if we could much the development of HTML to a
model where the stages are attached to features rather than the full
document. We could, for example, right now split out all those
features that are stable (i.e. satisfy the "Recommendation" criteria)
and call that document "HTML5 as of today's date". Then we could make
a list of features that are almost there and put them at "CR" level
saying that we are confident as a committee that this is stable, but
it just needs some more implementations. These could then also be
features that browser vendors could prioritize for implementation,
because they will have a large impact towards cross-browser
compatibility. And so on - you get the picture.

This is somewhat the way in which the W3C process is describing things
(as in: only features that are stable are allowed to enter "PR"
stage), but for whatever reason we in the W3C define maturity on a
per-feature level, but only publish on a document-level.

Maybe it has something to do with the version control systems that we
typically used: CVS and SVN are particularly bad at dealing with
branches and merges. But we have now moved to Mercurial, so a more
fluid approach to the creation of new features and their inclusion
into the full HTML spec is possible.

To me it makes sense to have a "stable" (or "PR") branch of the spec,
then a "CR" branch with includes the stable spec plus any features
that are almost there, and finally a "WD" branch with the features
that are still under development and highly likely to change. Features
will be "merged up" into the next stage branch based on group
decisions.

What we define as a "feature" can be rather flexible. It could be an
element with all its attributes and IDL and rendering requirements. It
could also be just a single attribute. It all depends on how much
discussion/support/objections a feature attracts.

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.

Sorry about the lengthy and somewhat off-topic reply, but you did ask. :-)

Cheers,
Silvia.


On Thu, Aug 11, 2011 at 10:55 PM, Sam Ruby <rubys@intertwingly.net> wrote:
> On 08/10/2011 10:12 PM, Tantek Çelik wrote:
>>
>> I tend to agree with Sylvia, and furthermore, am not convinced that
>> the current feature set of HTML5 is a good "checkpoint" by any
>> measure (implementation, feature stability, etc.) both from a
>> perspective of features in the draft and features outside the draft.
>>
>> I think letting HTML5 evolve a bit longer and seeing if there is a
>> convergence point among implementations and what features are or are
>> not supported would be a better approach.
>
> Do either of you have any specific features in mind?  Can you please verify
> that there are existing bug reports and/or that these features are added to
> the wiki page:
>
> http://www.w3.org/wiki/HTML/next
>
>> I don't think a spec-wide "Last Call" draft or period helps this
>> purpose and thus perhaps that aspect/phase of the process should
>> itself be called into question.
>
> We proceeded to Last Call based on the results of the following poll:
>
> http://www.w3.org/2002/09/wbs/40318/html5-last-call-poll/results
>
> I do encourage both of you to participate any such polls that we might have
> in the future.
>
>> Thanks,
>>
>> Tantek
>
> - Sam Ruby
>
>> -----Original Message----- From: Silvia
>> Pfeiffer<silviapfeiffer1@gmail.com> Sender:
>> public-html-request@w3.org Date: Thu, 11 Aug 2011 11:34:26 To: Maciej
>> Stachowiak<mjs@apple.com> Cc: HTML WG LIST<public-html@w3.org>
>> Subject: Re: HTML.next and Rechartering
>>
>> On Thu, Aug 11, 2011 at 8:57 AM, Maciej Stachowiak<mjs@apple.com>
>> wrote:
>>>
>>> Hello Working Group,
>>>
>>> Now that the Last Call period is over, it's a good time to start
>>> thinking about the next steps in the evolution beyond HTML5.
>>>
>>> There are a few ways we can start thinking and talking more about
>>> HTML.next:
>>>
>>> 1) Let's start up some discussion and collection of post-HTML5
>>> feature ideas.
>>>
>>> 2) Though we cannot yet publish post-HTML5 deliverables as Working
>>> Drafts, nothing stops us from creating Editor's Drafts. So current
>>> editors and anyone else who is interested are encouraged to create
>>> post-HTML5 proposed Editor's Drafts for consideration, in parallel
>>> with the versions working their way through the LC process.
>>>
>>> 3) To be able to publish post-HTML5 delieverables, we will have to
>>> change the charter of the Working Group. There are two possible
>>> tracks we can take: A) Come up with a detailed definition of the
>>> requirements, scope, and expectations for our next-generation
>>> deliverables, and cast that as a new charter. B) Update the current
>>> charter and give a fairly loosely defined scope for post-HTML5
>>> deliverables.
>>>
>>> Option A is much more clear about the next phase of our work, which
>>> is helpful in some ways, but it may require longer discussion to be
>>> clear about the scope. Option B likely requires less careful
>>> wording and negotiation. There is some interest in completing
>>> rechartering by the time of TPAC 2011. To achieve that, we'd have
>>> to have a draft charter ready in 3-5 weeks. We have W3C staff
>>> members who can help with the drafting.
>>
>>
>> Realistically, in 3-5 weeks, I don't think you can achieve 3.A) .
>> Also I wonder why we'd want to put a restriction on the features that
>> we want to add to HTML5. I think it's more productive to keep the
>> features open and just continue working on the spec. Which is in
>> fact already happening at WHATWG and it's good to stay in sync.
>>
>> Silvia.
>>
> http://www.w3.org/wiki/HTML/next
>
>

Received on Thursday, 11 August 2011 22:22:36 UTC