Re: CR exit criteria and features at risk for HTML5

On 8/16/12 5:55 AM, Sam Ruby wrote:
> Or an HTML 5.1.

Sure.  But why is it preferable to have an HTML 5.0 REC now if we know 
that we will definitely need a 5.1 soon and even know which spec 
sections will cause us to need it?  I would like to understand that 
part.  I'm not saying it's the wrong course of action; I just want to 
understand the reasoning!

And again, I would be much happier with this if I had faith that a 5.1 
would in fact happen.  My worry is that a 5.1 would be needed but NOT 
happen, based on my past interactions with the W3C.

> 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.

Yes.  If the plan for HTML were clearly to move to releases more often, 
or even to commit to ongoing releases at all, then this would all make a 
lot more sense.  But every time someone suggests something like that 
there's a huge amount of pushback.

> 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.

I guess it depends on what the purpose of replacing it is and how long 
we plan to treat the new thing as "HTML".

> 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?

The latter, if we're actually doing it.

> 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?

Yes.  And ideally we make a point of shipping only the non-fictional 
parts of the spec (in contrast to 4.01, note!).

> 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

Well, I'll be honest.  I don't see the value of REC as currently set up. 
  Which is why I'm asking for someone to explain it to me, please.  How 
we move towards REC really depends on what the goal of a REC is, and 
_that_ is what I'm trying to understand in this context.  In terms of 
browser interop, a REC for something unmodularized the size of "HTML" is 
somewhat pointless as far as I can tell; the really important part for 
interop is stabilizing the spec text to a large degree and 
implementations converging on it.  So presumably having a REC has some 
other goals.  What are those goals?

> 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

The HTML spec is an interesting case, compared to most W3C specs.  It 
consists of more or less two parts.  The first part is features as you 
describe them (the common case for W3C specs).  For those, handling as 
you describe makes perfect sense.

The second part is an attempt to specify long-standing parts of the web 
platform that no one has ever tried to specify before.  Some parts of 
this are pretty solid (e.g. the parser).  Others are more speculative. 
Are we willing to defer these foundational pieces (which other parts of 
the spec depend on!) as needed to prevent freezing them in an unusable 
state, or at least commit to a REC not meaning they're frozen?  _That_ 
is the part that I'm interested in on a practical level.


Received on Thursday, 16 August 2012 14:13:20 UTC