W3C home > Mailing lists > Public > public-html@w3.org > October 2012

Re: [HTMLWG] CfC: Adopt "Plan 2014" and make some specific related decisions

From: Jonas Sicking <jonas@sicking.cc>
Date: Fri, 19 Oct 2012 00:47:12 -0700
Message-ID: <CA+c2ei_x0RO22wiCX4013jB7r53afWPbMCteUD2UxYQ_kV5Bqw@mail.gmail.com>
To: Sam Ruby <rubys@intertwingly.net>
Cc: public-html@w3.org
On Oct 12, 2012 4:25 AM, "Sam Ruby" <rubys@intertwingly.net> wrote:
> On 10/11/2012 12:02 PM, Henri Sivonen wrote:
>> I object to taking an Extension Specification to FPWD simply when a WG
>> participant offers a draft.
> We have never done that.  We have always done a call for consensus prior to publishing.

The problem with making FPWD a checkpoint for "will receive HTML
branding" is that a draft can change dramatically after that. It
basically means that if a draft at some point receives the HTML stamp,
it will then carry that recognition no matter what changes are made to

You could argue that we will have CfCs for each WD that is published
and that people can then speak up if it changes for the worse since
last publication.

There are three problems with that:

1. We generally should be encouraging people to look at the editor
drafts since published documents quickly get out of date.

2. We constantly have to make tough calls on if a new spec has the
right number of "support" versus "oppose" responses for the CfC.

3. It requires a very large community of people to constantly monitor
this mailing list to see if there is something they need to object to,
and make those decisions in relatively small amount of time. This
makes going on vacation a risky proposition for example.

A better solution is in my opinion for extension specs to carry their
own weight without relying on branding. This can be accomplished by
simply being careful about what we choose to put in the status section
of the drafts. So for example clearly stating that it's not a HTML WG
draft. And stating that though its published by W3C as a extension to
HTML, it's not actually part of HTML and might never be so.

That said, I really like the direction that the original proposal in
this thread takes.

The HTML spec has gotten so big that it carries its own momentum. That
means thar whatever goes into it will be carried by the HTML momentum
rather than its technical strength.

By making use of extension specs we can instead let the market decide
what makes it and what doesn't. Which I think is a great idea.

But in order for that idea to work we need to ensure that the language
in the drafts are clear enough that it actually is the technical
contents of the draft that gives it momentum, not association,
misunderstood or otherwise, with the HTML WG.

> Concrete proposals welcome.

I hope the above counts as a concrete proposal.

/ Jonas
Received on Friday, 19 October 2012 07:48:10 UTC

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