W3C home > Mailing lists > Public > public-html@w3.org > June 2010

Re: Differences between the W3C and WHATWG specifications

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 14 Jun 2010 10:41:14 +0200
Message-ID: <4C15EB2A.2000309@gmx.de>
To: Ian Hickson <ian@hixie.ch>
CC: Sam Ruby <rubys@intertwingly.net>, Philippe Le Hegaret <plh@w3.org>, HTML WG <public-html@w3.org>
On 12.06.2010 19:08, Ian Hickson wrote:
> On Sat, 12 Jun 2010, Sam Ruby wrote:
>>   * The Atom section is not listed in either the list of "minor"
>>     differences, nor is it listed in the features that are
>>     considered part of the next generation of HTML beyond HTML5.
> Fixed.

This is an improvement, but...



"Is this HTML5?

This section is non-normative.

In short: Yes."

But it goes on saying:

"Features that are considered part of the next generation of HTML beyond 
HTML5 (and that are therefore not included in the W3C version of HTML5) 
currently consist of:

o The device element.
o The ping attribute and related hyperlink auditing features.
o The timed track model for media elements, the WebSRT format, and 
related features.
o Rules for converting HTML to Atom."

I appreciate the clarification that these things are not part of HTML5, 
but then, why put them into a document that claims to define HTML5?

Going back to the original discussion... My proposal is that the W3C 
document either does not mention the WHATWG version, *or* is clear about 
what the referenced document is. It currently says:

"The latest editor's working copy (which may contain unfinished text in 
the process of being prepared) contains the latest draft text of this 
specification (amongst others)."

This is misleading, as the referenced document contains text that is 
neither HTML5, nor part of other specifications, unless you rely on the 
reader to be aware that "beyond HTML5" is one of these "other" 
specifications, and that the contents is mixed into the HTML5 spec 
(without this being noted in the places where it appears).

 > ...
> amongst each other. The WHATWG draft continues to exist because it's the
> only way to have a specification that actually makes sense in the face of
> the ridiculous decisions you keep making. At least so far the decisions
> ...

Just clarifying: so it continues to exist because you need a vehicle to 
bypass W3C WG decisions?

> ...
> Right now the process is biased towards two groups: those who are willing
> to complain loudest, and those who are willing to raise the least
> important issues. It is biased against those who apply reason and
> restraint. Every issue so far has carried in favour of the side who raised
> the most and loudest arguments, regardless of the validity of those
 > ...

That is not true.

> arguments. Heck you didn't even dismiss Julian's ridiculous issue about
> what reference we should use for ASCII, which is the most frivolous issue
> I've ever seen a working group take on in my decade at the W3C. You are
> literally encouraging people to process troll.

I agree with you that it is sad that we need a two stage escalation 
process to fix an editorial issue. But you are the editor, and you chose 
to ignore feedback. Deal with it.

> ...
> The reference to WCAG that is omitted is redundant with one in the
> introduction section. Including it makes the spec inconsistent as there is
> nothing special about the place where it is included. I considered
> rejecting the bug that asked for it but why bother? It would just have
> been escalated and then you'd have argued there was no reason not to
> include it, since the most vocal arguments would have been from those who
> support WCAG and want it mentioned at every turn, and the people who
> don't think it's necessary would all consider the issue too minor to
> spend time on, which would mean you would end up deciding the issue in
> favour of adding the reference anyway, making up some nonsense reason for
> why the reference should be there.
> ...
> Easier to just add the reference in just the W3C version and keep the
> WHATWG version sane.
 > ...

Where apparently there's disagreement about what is more "sane".

I think it would be much more productive to simply apply the editorial 
changes that were requested, instead of making the gap between the specs 
even wider.

Best regards, Julian
Received on Monday, 14 June 2010 08:42:04 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:20 UTC