Re: CR exit criteria and features at risk for HTML5

As always, everything I write is my own opinion and not that of my
employer (which is currently Mozilla).

On Wed, Aug 15, 2012 at 2:43 AM, Maciej Stachowiak <mjs@apple.com> wrote:
> === Strict version
>
> For this specification to be advanced to Proposed Recommendation, there must be at least two independent, interoperable implementations of each feature.

I strongly object to this set of criteria.  It will result in HTML5
not reaching REC until it's so old that it's absolutely useless as a
reference work.  All useful information that's in HTML5 will be
contained in newer standards, but the newer standards will also have
years of work put into them that HTML5 will lack.  If nothing else,
there will be countless new features that HTML5 will not document by
that point, so it's unlikely any browser implementers will look at it.

Implementers should really only be looking at the latest ED.  We've
had implementers get confused more than once by accidentally looking
at a draft that's just a few months outdated, never mind years.  As
such, any stabilized HTML draft is useless to implementers anyway.
(This doesn't necessarily apply to other standards, which might
document more stable technologies.)

As such, the only value I can see in having an HTML5 REC at all is the
patent policy.  From a patent-policy perspective, we want to publish
as much material as possible as REC, as often as possible.  Increased
standards for REC mean both greater delay of publication, and less
material published (because features that aren't well-tested or
interoperably implemented need to be dropped to progress).

Thus I support the absolute minimum requirements necessary to get to
REC.  Ideally, I would like the spec to be moved to PR immediately
with no consideration of technical interop at all.  Given that this is
currently against W3C Process, I'm fine with the "permissive" approach
outlined here.

On Thu, Aug 16, 2012 at 10:21 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> Well, a good start would be having a simple, advertized way to contribute
> tests.  I don't even know how I'd go about contributing a test for the HTML5
> test suite, and my experience with contributing tests for other W3C working
> groups has been less than pleasant.  :(

Contributing tests to the HTML and WebApps WGs is actually so easy
that it would be hard to make it any easier.  But it's still
unnecessary effort if you're trying to fix a bug, so people don't do
it even if they know perfectly well how, like I do.  In fact, I've
routinely fixed editor bugs and written only internal Mozilla tests
for them -- despite the fact that I'm the sole editor and test
maintainer of the editing test suite, and all I have to do to submit
and approve tests is check them into the repo I maintain!

What needs to happen is browsers enforcing a policy of writing all
their tests in reusable formats, and then making sure they submit
them.  I just suggested such a policy for Mozilla:

https://groups.google.com/forum/?fromgroups#!topic/mozilla.dev.platform/AUJaVnuGFKI%5B1-25%5D

But that still won't ensure that we get comprehensive testing.
Browsers don't have comprehensive internal tests by any means.
Realistically, the relevant standards will always have plenty of bugs,
just like the implementations do.  Except more, because browsers have
more manpower and more direct incentives to do things that make sense.

Defining REC as something that doesn't exist (like "spec that's fully
tested and interoperably implemented") isn't going to make it exist.
Specs for large, complicated parts of the platform will always be
works in progress.  And any parts that are stable will have so many
unstable things built on them that separate specs for only the stable
parts wouldn't be useful to anyone anyway.

So I think we should get HTML5 to REC as fast as possible for patent
reasons, and continue using the WHATWG(/WHATCG) HTML draft for actual
implementation.

Received on Thursday, 16 August 2012 11:29:08 UTC