[whatwg] A New Way Forward for HTML5

[Peter Kasting]

On Thu, Jul 23, 2009 at 2:48 PM, Manu Sporny <msporny at digitalbazaar.com>wrote:

> contribute ideas: great!
> scrutinize them: wonderful!
> form consensus: fail (but that's what the W3C is for, right?)
> produce: fail (unless we don't want to scale the community)
>
> Ian is really the only one that is actively allowed to produce anything
> of significance in WHAT WG. In general, if he doesn't agree with you, it
> doesn't go in.


It's already been stated explicitly multiple times in the past that the
HTML5 process is not ultimately consensus-driven, so this shouldn't be news
to anyone.  I for one consider that a feature, not a bug.

I think it's fair to say that one needs to have a pretty
> significant chunk of time on their hands as well as technical chops to
> make a contribution to the HTML5 specification.


Incorrect.  All sorts of people have made contributions of small
corrections, opinions on issues, spec proposals, etc.  Ian has publicly
committed to reply to every email and so far I see him doing precisely that;
frequently this results in spec changes.  When people's opinions are
ultimately rejected, it is not without due consideration first.

To approach the issue from another angle, we have roughly 1,000 members
> on this mailing list and could have close to 1 billion people[1] that
> could be using some form of HTML by 2012, a number of those are web
> developers (read: a huge developer base).
>
> The Linux kernel mailing lists have close to 30,000 members[2], and I
> don't think it's a stretch to say that there are fewer kernel developers
> in the world (read: small developer base) than there are web developers
> and designers. So, I've been wondering about the 30:1 discrepancy.


You're comparing non-analogous situations.  LKML is inherently of interest
to all kernel developers, pretty much by definition.  The HTML spec creation
process is not inherently interesting to all web developers.

A closer analogy would be to the engineers working on HTML support in UAs.
 I suspect that this mailing list _is_ inherently of interest to that group.

We don't give anybody the impression

here that they could directly impact the specification if they so
> desired.


If people sending emails containing proposals, and having the editor
directly respond to all of those emails, frequently by changing the spec,
does not give you the impression you can impact the specification, I'm not
sure what would.

I can git clone the Linux kernel, mess around with it and submit a patch
> to any number of kernel maintainers. If that patch is rejected, I can
> still share the changes with others in the community.


Similarly, nothing prevents UA authors from coding any feature they wish and
hoping it will gain traction.  Similarly, nothing in the HTML5 process
prevents anyone from proposing a feature that has been rejected by HTML5,
and attempting to convince UA authors to support it directly.  To the degree
that these don't happen, it is because practical considerations make success
unlikely: it is much more difficult for a random web developer to convince a
vendor to support his idea in a particular UA than for a random coder to
post a patch online alongside a modified kernel build.

(However, it is not impossible: at least Firefox and Google Chrome can be
built, as non-branded versions, from source by any interested party; and in
fact that capability has been used for precisely the above purposes: see
e.g. Iceweasel.)

Similarly, people
> that are creating user agents tend to not care about examples (in
> general)


Speaking as one of those people, you are completely mistaken.  Examples are
highly useful to UA authors.  And implementation details are occasionally
useful to web developers, insofar as they document expected behaviors very
precisely and thus are useful when trying to test how real-world UA
behaviors differ.

I think the only valid point here is that web developers trying to read the
spec directly probably want the "implementation details" as a reference
rather than inline.

They should be able to edit /something/ lasting, publish it for review,
> and rise or fall on the merits and accuracy of their specification
> language. They are not being given the opportunity to do so.


Anyone can post a proposal anywhere on the web, which they themselves edit.
 If they want the imprimatur of the WHATWG, then it seems reasonably to
expect that that proposal would have to be accepted by the editor(s) of that
group.

I'm not sure why there is a perceived lack of clarity here.  Rejected
proposals are always given concrete rationale for rejection (IMO).

it
> was meant as a feeler document to see how this community would react to
> the proposed changes.


For my part, I would be very unhappy to see the HTML5 process made more
consensus-driven; I much prefer systems that approximate benevolent
dictatorships, and I don't perceive the current leadership of the group to
be insufficiently responsive to communication.

PK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090723/eddc098a/attachment-0001.htm>