Re: CR exit criteria and features at risk for HTML5

On Thu, 16 Aug 2012 16:12:49 +0200, Boris Zbarsky <bzbarsky@mit.edu> wrote:

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

FWIW I strongly disagree with your assessment that W3C will not work on  
HTML.next, whatever that is called. (5.1, 6, "Next", "Klingon", ...). They  
have worked on 3, 3.2, 4, 4.01, XHTML 1.0, XHTML 1.1, XHTML 1.2, XHTML  
2.0, HTML 5 and are *currently* working on HTML.next, as well as SVG 1,  
1.1, 1.2 and now working on 2, CSS 1-4, ...

This seems to suggest that while sometimes things aren't as timely or even  
as useful or good as we would like them to be, and in many cases despite  
effective pressure "not to finish".
I am aware of bugs filed against W3C specs with the deliberate goal of  
slowing them down which in consequence holds back the process of producing  
successive releases. Of course there are also many ways that people  
already slow down specs in a good-faith quest to improve their quality.  
Sometimes specs are not as good, or useful, and often not as timely, as we  
would like. Nonetheless I think overall W3C has a reasonable record of  
publishing a version as a Recommendation and moving forward.

(And as James said, WHATWG was formed with an intent to keep the pressure  
on development of HTML and as far as I can see it is very successful in  
that regard).

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

I read your email in this thread as pushback to publishing a version now  
and being able to release a new version sooner. Since I assume that's not  
your intention, it would be worth clarifying why we seem to be talking  
past each other.

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

Until we have something better that we can ship as a version...

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

As Glenn said, there are many organisations who will not refer to a work  
in progress. If you make a contract with someone to deliver something, it  
doesn't necessarily have to be perfect (or no browser would ever have  
shipped). But it is very helpful when estimating the cost to have a known  
target.

Stabilising something reasonably recent provides a good trade-off between  
predictability and functionality for many who invest zillions of dollars,  
rubles, yen, rupiah, reais between predictability and functionality.

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

A REC doesn't freeze those parts (although it can help solidify the ones  
that are not too brittle to need revision again soon). HTML5 happily  
"unfreezes" things that were baked into HTML 4, to better match modern  
reality...

cheers

-- 
Chaals - standards declaimer

Received on Thursday, 16 August 2012 17:17:30 UTC