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

Re: Request for editing guidance

From: Sam Ruby <rubys@intertwingly.net>
Date: Thu, 10 Jun 2010 09:35:37 -0400
Message-ID: <4C10EA29.8020100@intertwingly.net>
To: Ian Hickson <ian@hixie.ch>
CC: public-html@w3.org
On 06/08/2010 10:21 PM, Ian Hickson wrote:
> I can't edit the spec if I'm going to be instructed to make edits that
> make the spec internally inconsistent, with sections left in or taken out
> apparently arbitrarily: I simply don't know how to edit the spec in this
> situation.

Items appear in the WHATWG specification based on the individual 
discretion of the author, often without any documented rationale.  Items 
which are challenged and for which no rationale is provided (examples 
cited below include the ping attribute and the OCR paragraph) are 
removed from the W3C specification, and the decision to do so is 
carefully documented and published.

> These are all virtually identical: they provide UAs with explicit
> permission to do something that a strict reading of the spec might suggest
> to over-enthusiastic implementors is not allowed. I honestly can't tell
> from 0001 what the reason to remove the OCR paragraph is, except maybe a
> vague and unsupported reference to a "widespread" (but wrong, mind you)
> "belief that the text is 'not useful, confusing, and potentially
> harmful'", whose counter argument (that the text is an improvement over
> nothing) is described as lacking "evidence or rationale", despite it
> pretty being self-evident as far as I can tell.

First, the above makes the implicit assumption that the UUAG does not 
exist ("improvement over nothing").

Second, what is self evident to me that the inclusion of any text that 
is not useful, confusing, and potentially harmful is emphatically NOT an 

Which leaves the question of whether this particular text is not useful, 
confusing, and potentially harmful.  Evidence would be helpful.  Claims 
of that it is "self-evident" are not sufficient.

> Here's another concrete example:
> 0002 cited above and the microdata decision cited above put forward nearly
> identical arguments, yet reach diametrically opposite conclusions. Both
> microdata and<figure>  have been specified, have rationale, have support
> from implementors and developers, have counter-proposals that are also
> specified (in the case of<figure>, HTML4+ARIA, in the case of
> microdata, RDFa), both could be specified in a modular fashion, though
> in both cases doing so results in a fractured language, both are
> intrinsically part of HTML though in both cases an argument could be made
> that it could be turned into a generic vocabulary, both are immature
> (<figure>  even more so), and so on.
> Yet the chairs reached diametrically opposite conclusions, while citing
> these characteristics as being the reason for the conclusions.
> Why?


The two surveys were of the form "place microdata here or there?" and 
"figure element: keep or chuck?".  The questions before us were not even 
of the same form, which makes it difficult to come to conclusions which 
are "diametrically opposite".

> Frankly the only reason I can see is the idea that within the
> self-selected group of vocal people who spoke up on the subjects, one had
> more people arguming in favour and one had more people arguing against.
> But if that is going to be the actual way we edit the spec, then we need
> to dispense with the ridiculously expensive and heavy-weight process we
> have now wherein we pretend that the chairs make a considered decision,
> and just have straw polls for anything anyone objects to. Such a decision
> mechanism will lead to a highly inconsistent, "compromise by committee"
> spec, and is not something I'm interested in participating in.

Here you are ignoring the cited and carefully documented reasons, and 
inserting your own interpretation.

> I hope, however, that that isn't the actual process that we are following.
> Certainly, in public the chairs have repeatedly said that that is not the
> process we are following, and that instead quality of arguments is what
> matters. I hope that there are underlying principles that I can
> consistently apply that I simply haven't been able to figure out.
> What are they?
> Other concrete examples:
> Why is ping="" out but hidden="" in?

Ping is out because nobody made the case to keep it in:


Hidden has yet to be decided:


> Why is microdata in its own draft but class="" not?

"maturity, market success, and reusability":


> Why is postMessage() split out but showModalDialeg() not?
> Why is the 2D context interface out but ApplicationCache not?

In both cases, because YOU made the decision to do it:


Neither of the splits mentioned above are the result of a WG decision.

To my knowledge, nobody has ever asked for postmsg to be published as a 
FPWD.  Nor commented on its absence.  Despite the fact that it the API 
itself is mentioned in the security section.

> So again I ask:
> Could you please write a coherent statement of editing guidance that I can
> consistently apply to the spec to make it consistent with the working
> group decisions throughout?

I endorse Charles McCathieNevile's input:


- Sam Ruby
Received on Thursday, 10 June 2010 13:36:09 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:03 UTC