Re: CR exit criteria and features at risk for HTML5

Hi sam,

you wrote:

Or an HTML 5.1.
>

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 think it would be worthwhile for such ideas to be fleshed out so we could
get an idea of a changed process/cycle and what cost/benefits this would
bring.

 regards

SteveF

On 16 August 2012 10:55, Sam Ruby <rubys@intertwingly.net> wrote:

> 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 <mjs@apple.com>
>>> 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 HTML.next.
>
>  -Boris
>>
>
> - Sam Ruby
>
>
>
>
<http://www.paciellogroup.com/resources/wat-ie-about.html>