Re: CR exit criteria and features at risk for HTML5

On 08/15/2012 11:26 AM, Boris Zbarsky wrote:
> On 8/15/12 11:10 AM, Henri Sivonen wrote:
>> On Wed, Aug 15, 2012 at 2:43 AM, Maciej Stachowiak <> wrote:
>>> W3C Management feels strongly that getting to REC quickly is
>>> essential, and more important than creating an extensive test suite
>>> or proving interoperability in detail.
>> Can reasoning be provided for this strong feeling?
> Indeed.  Experience shows that the result will most likely be a REC that
> can't actually be implemented without breaking web compat, so UAs will
> either not follow the REC or errata will be needed on an ongoing basis.

Or an HTML 5.1.

> Which raises the question of why such a REC is better than a CR that is
> updated based on implementation and testing feedback.  I would really
> like to understand the reasons why W3C Management thinks it is.

I won't speak for W3C management, but only for myself.

I see you tossing around words like "bogus".  I could ask the same about 
shipping implementations, yet each continues to make releases.  In fact, 
the current trend is to make releases more often.

The current REC is HTML 4.01 which is dated 1999.  I hope that we can 
agree that that is pretty bogus, and needs to be replaced ASAP.

Should we wait another half a decade or decade or more and try to get to 
nirvana in one step, or should we attempt to make incremental progress?

Or do we ship HTML5 when it is demonstrably better than HTML 4.01, and 
set things up for the REC to be replaced more frequently than once a decade?

I'm pleased to see much of this discussion is around testing.  Parts of 
it come awfully close to "some people or organizations don't see the 
value of REC, so by delaying something they don't care about, we will 
get more tests".

I'm skeptical that such arguments will convince anybody.  Either to 
contribute or to delay.

What would make such arguments more credible is a bottom's up schedule. 
  "For feature X to be included, we need tests Y to be written, 
debugged, submitted, and get implementations to pass.  The schedule for 
this to be complete is: Z".

Meanwhile, a focus on REC would help us jointly prioritize this work. 
Features that are of low value (for whatever reason) and will take 
longer (for whatever reason) can be deferred to

> -Boris

- Sam Ruby

Received on Thursday, 16 August 2012 09:56:12 UTC