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

[whatwg] Technical Parity with W3C HTML Spec

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 25 Jun 2010 09:11:41 -0700
Message-ID: <AANLkTind4DFWdc9BLy1XANmWHt0zFK8yHLiwSCbPIoob@mail.gmail.com>
On Fri, Jun 25, 2010 at 3:13 AM, Doug Schepers <doug at schepers.cc> wrote:
> Hi, WHATWG folks-
>
> 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.
>
> I'm not trying to be political about this, but since W3C and WHATWG are
> meant to be collaborating, there has to be a certain amount of of
> flexibility from both sides, for the good of the standard itself, and for
> readers of the spec.
>
> 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'm not sure why.  The two-group development that HTML has is very
weird, and most of the conflict wouldn't exist if one group or another
did everything.


> Option 3 results in the
> problem we have now (though having an explanation for each difference would
> be an improvement; I don't know of any such wording now).

Look in the introduction of the WHATWG spec.  It lists every
difference between it and the W3C spec, along with a short explanation
as to why the difference exists.


> This leaves option 4. ?W3C has a relatively clear method for resolving
> conflicts: first, the group tries to settle the issue on the merit of the
> technical arguments; failing that, the group may hold a poll (with each
> individual or organization given a single voice); if there is no consensus,
> the chairs of the group can make a ruling based on the reasoning at hand; if
> there are still Formal Objections to the results of that poll, the group can
> escalate the issue up to the Domain Lead, and ultimately all the way up to
> the W3C Director (who is normally Tim Berners-Lee). ?Obviously, the strong
> preference is not to get to the poll stage at all. ?I don't know of any W3C
> method for dealing with conflicts between different standards bodies, like
> W3C and WHATWG, so I think we're in the air here; W3C obviously has no
> authority over decisions made in WHATWG, but we need to find a way to
> resolve these conflicts.
>
> As I understand it, the editor seems to have final decision-making power in
> WHATWG, and I don't know of any process for appealing those decisions
> (assuming you would want to); for the purposes of arbitration between
> groups, how can we proceed?

The WHATWG has a steering council made up of browser developers.
Officially, they can override Ian's decisions or make him step down as
editor.  They've never had to exercise this power yet, though.


> For the record, here's my suggestion:
>
> a) Both WHATWG and W3C should maintain a single definitive HTML5
> specification, that is a feature-for-feature match between groups

This begs the question.  At the moment, the WHATWG version is a pure
superset of the W3C version.  This may not be the case in the future.
Should the two-group spec be the intersection of the two individual
specs?  The union?  Something else?  Reconciling the two specs is
*precisely* what the problem here is that we're trying to solve.


> b) For the longer-term WHATWG work, including sections that were once part
> of the HTML5 spec but were split off into separate specs (Canvas API) or
> removed (datagrid), there is another "Master Spec" that includes whatever
> the editor feels is needed in that spec, so long as it doesn't conflict with
> the HTML5 or related specs

Yeah, that's the Complete spec here at WHATWG -
http://www.whatwg.org/specs/web-apps/current-work/complete/.


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

Again, begging the question.  Where there have been conflicts, the
WHATWG has decided definitely how to resolve them for itself - that
is, Ian decided, and the steering committee didn't disagree
sufficiently to override him.  What else can be done here?


> Maybe the answer is to have a spokesperson or liaison role, someone
> respected in the WHATWG community with a reputation for reasonable
> neutrality? ?Both Hixie and Maciej have conflicts of interest, as editor and
> W3C co-chair respectively. ?Maybe H?kon or David, since they were
> instrumental in forming WHATWG in the first place?

What would this spokesperson do?  What happens when the WHATWG decides
something different from the W3C and the liaison can't resolve the
differences?  We're in the same situation as right now.

Let's return to Options 1 and 2.  HTML5 began its development in the
WHATWG, and spent several years there before the W3C officially
blessed it.  Nearly all development work continues to occur in the
WHATWG, with little or no technical work occuring in the HTMLWG.  If
the HTMLWG were to sink into the earth tomorrow, HTML5 would truck
along with nary a hiccup.  Thus, continuing work solely in the WHATWG
would be a practical choice.  The major problem with this approach is
that the WHATWG does not have a decent patent policy (or any at all,
for that matter), which appears to be a concern for Microsoft.  (I
assume it's somewhat of a concern for other browser vendors, but was
considered small enough that they still thought the WHATWG was
worthwhile.)

Alternately, we could continue work solely in the HTMLWG.  This would
not be possible unless we change the way the HTMLWG works somewhat,
though.  There's a *reason* that almost no technical discussion
happens within the HTMLWG.  If we were to pursue this option and
actually try to keep HTML5 alive, we'd effectively just be continuing
work in the WHATWG, but painting over the clubhouse sign with
"HTMLWG".

~TJ
Received on Friday, 25 June 2010 09:11:41 UTC

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