W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2010

[whatwg] Technical Parity with W3C HTML Spec

From: Aryeh Gregor <Simetrical+w3c@gmail.com>
Date: Fri, 25 Jun 2010 18:30:53 -0400
Message-ID: <AANLkTinDKsGR8AYr8ikKDAZvwnjUQarQ76x0TrDUNmKw@mail.gmail.com>
On Fri, Jun 25, 2010 at 6:13 AM, Doug Schepers <doug at schepers.cc> wrote:
> As you are probably aware, some differences have arisen between the W3C
> draft of the HTML5 spec and the larger WHATWG version. ?In my opinion, the
> specific technical details of any given feature (which, let's be fair, are
> often more-or-less arbitrary) is of lesser importance than there being a
> single definitive version that is consistent between both organizations.
> ?The whole point of an open technical standard is to promote
> interoperability between implementations, and having conflicting or
> ambiguous specs will not result in that goal.

The specs do not conflict.  The WHATWG spec is a superset of the W3C
one as far as all requirements go.  The parts that are in both differ
only in non-normative things like examples and "implementers may do
X".

> There are a few possible ways to handle this:
> 1) W3C could match the WHATWG version in all details, with all decisions
> made by WHATWG
> 2) WHATWG could match the W3C version in all details, with all decisions
> made by W3C
> 3) WHATWG and W3C could maintain different specs with different details, and
> list the differences with an explanation for each
> 4) WHATWG and W3C could adopt decisions made in each group, and where there
> is conflict, decide upon some method of settling the difference of opinion.
>
> Options 1 and 2 are obviously both unreasonable.

I think those are the only two reasonable options.  One body should
make the decisions.  It would be totally fine if that were the HTMLWG,
as long as the current insanely bureaucratic structure were scrapped
and replaced with a typical one, where the editor makes most decisions
and can be overruled only by a few members (who would be implementers
in our case).  But Ian doesn't want us discussing that here, so I
won't elaborate further here.

> c) Where there are technical or political conflicts, WHATWG should decide
> how to resolve those internally, and how to represent the WHATWG point of
> view in the W3C HTML WG. ?I would expect that people differ, so I would
> expect those different opinions to be represented in liaisons with W3C. ?I
> don't have a good answer here, because I think it's up to the WHATWG to
> decide their own processes, but I hope we agree that we need improvements to
> how we liaison.

I think the problem is that the groups are structured so differently,
particularly that the WHATWG is controlled entirely by implementers
while the HTMLWG gives a great deal of say to anyone who wants to sign
up and voice an opinion.  Communication isn't the problem.

On Fri, Jun 25, 2010 at 6:06 PM, Mike Shaver <mike.shaver at gmail.com> wrote:
> "Editors should reflect the consensus opinion of the working group
> when writing their specifications, but it is the document editor's
> responsibility to break deadlocks when the working group cannot come
> to an agreement on an issue" doesn't sound like the working group can
> override anything, and only goes as far as "should".
>
> It turns out that two of the Members are in the same building as me,
> though, so I'll go see what they think the model is. ?I think they may
> be surprised to discover that they could have overridden Ian on
> anything!

I'm pretty sure they won't be.  Any significant implementer has always
had veto power over the spec.  For example, Mozilla vetoed Web
Databases, and Apple vetoed Theora requirements, by just saying they
wouldn't implement them.  Ian has always made it clear that he'll spec
whatever the implementers are happy with.  For instance, a few days
ago in #whatwg (lots of lines deleted for readability):

[100622 17:18:08] <ap> Hixie: we shipped something that matched the
draft spec, is there a good reason for it to change under us? this
seems like a completely arbitrary change
[100622 17:19:58] <Hixie> but the reason for this change was a
discussion on public-webapps which had people from webkit, mozilla,
and opera and which decided that we should consistently use lowercase
attribute names so as to not make authors go crazy trying to work out
what was lowercase and what was uppercase
[100622 17:25:06] <Hixie> I was on the side of going all uppercase,
but that had a higher cost than going all lowercase except Document
[100622 17:27:35] <Hixie> ap: if you want to change the decision,
convince opera and mozilla to go the other way.
[100622 17:30:32] <Hixie> ap: i'm not the one you have to convince
[100622 17:32:07] <ap> Hixie: who should I convince?
[100622 17:32:22] <Hixie> reopen the thread on public-webapps and get
the participants to agree to implement the opposite

This is common.  Since Hixie never knowingly specs anything that
implementers aren't all willing to implement, and since basically
everyone else on the steering committee is an implementer, they've
never had to explicitly cite their authority as the steering committee
to overrule him.
Received on Friday, 25 June 2010 15:30:53 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:24 UTC