[whatwg] A New Way Forward for HTML5

[Manu Sporny]

L. David Baron wrote:
> The above document says:
> 
>   # The single greatest complaint heard from the standards community
>   # concerning the development of HTML5 is that it has not allowed
>   # for the scientific process.
> 
> I strongly disagree with this statement.  A key part of a scientific
> process is that the starting point is evidence.  I think the
> development process of HTML5 gives arguments based on evidence more
> weight than any other W3C work I've been involved in, and has put
> more effort into gathering relevant evidence than any other W3C work
> I've been involved in.  This is a good thing.

Hrm, that paragraph is problematic, others have had the same reading as
you have on it as well, which is not the message that I had intended.
Granted, it's meant to be an introductory paragraph which I spend the
rest of the document elaborating on, but perhaps it needs to be revised.

It's not the 'gathering of evidence' that I find problematic - quite the
contrary, I think that's a great way to deal with some these issues and
it certainly has helped solve some rather hairy disagreements in this
community.

It's the unevenness in the ability to directly contribute to the
specification that is the "walled garden" that I take issue with:

"""
Throughout history, the ability to openly contribute ideas, scrutinize
them, and form consensus around those ideas has been shown to produce
the most desirable outcomes. HTML5 is currently a walled garden that
must be opened to the greater standards community in order to ensure a
stable framework for the future of the Web.
"""

So, addressing those point-by-point related to how the WHAT WG operates:

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.

To put an HTML5+RDFa proposal together, I had to go outside of this
community. 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.

To understand why this is viewed as an issue, we can look to the
Microformats community, which has roughly 1,300 mailing list members.
Everyone is able to contribute to the main product of that community:
The Microformats wiki. Why isn't it the same in this community -- a
community that prides itself on being open to everyone?

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. Sure,
the WHAT WG has been more successful in getting members than HTML WG...
but what's keeping more people from joining?

I'm asserting that it has something to do with developers not feeling
like they can make a difference. We don't give anybody the impression
here that they could directly impact the specification if they so
desired. Our "scientific process" isn't open for all to participate at
every level of the community.

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. Using the same
tools as everybody else, I can refine the patch until there is a large
enough group of people that agree, and implementation feedback to back
up the patch, where I may have another chance of resubmitting the patch
for re-review. This mechanism is a fundamental part of the community.

I'm going to state that again, because that is the point I'm making here:

The ability to directly affect change at all levels of this community by
anybody that chooses to do so should be behavior that we should be
supporting, not stifling. The process that we have favors a select few
and forces the rest into being casual observers.

> Regarding the section "Action: Splitting HTML5 into Logically
> Targeted Documents", I agree that there is value in splitting the
> specification.  However, I see significant danger in the way you
> propose to split it:  separating the specification of what is
> available to authors and what should be implemented means the
> specification risks promising to authors what cannot be implemented,
> or cannot be implemented at a cost proportionate to the benefit (as
> HTML4 did in a number of places).

I may have not done a good job of expressing the purpose of
microsections. The purpose of microsections would be to create as much
language that could be re-used in each document as possible. Take the
<progress> element for example:

http://www.whatwg.org/specs/web-apps/current-work/#the-progress-element

Web Developers, in general, don't care about the "User Agent
Requirements" parts of that section, which constitutes almost half of
the content for the progress element. That is, they don't tend to care
(in general) about how the browser does what it does. Similarly, people
that are creating user agents tend to not care about examples (in
general) and would like to know more about the DOM Interface.

They would probably rather see examples of how to use the element
correctly. So, we have 3 possible microsections:

progress-element-introduction
progress-element-ua-requirements
progress-element-examples

These microsections could be used to generate two separate documents
from the same source:

HTML5: The Language - Syntax and Semantics, would contain
  * progress-element-introduction
  * progress-element-examples

HTML5: Parsing and Processing Rules, would contain
  * progress-element-introduction
  * progress-element-ua-requirements

HTML5: Ian Hicksons Specification, would contain
  * progress-element-introduction
  * progress-element-examples
  * progress-element-ua-requirements

> I'm a little bit puzzled by the inclusion of the section "Problem:
> Partial Distributed Extensibility":  it seems to be a technical
> issue (although a far-reaching one) in a document otherwise about
> process issues.  I'm not sure it belongs in this discussion.

Other reviewers of the document had said that as well. Perhaps it is not
desirable to talk about it in this discussion (which is about
process)... but I thought it should be mentioned (and will be brought up
in the coming months). I think that there are enough people that care
about it to author some spec language to guarantee that round-tripping
between HTML5 and XHTML5 is possible. That is, that xmlns: is preserved
in the DOM in HTML5. Although, you're right, that's a discussion for
another time.

> Finally, regarding the section "Problem: Disregarding Input from the
> Accessibility Community".  I think some of the input that has been
> ignored or has been felt to be ignored is input that is difficult to
> act on. 

I agree with the majority of what you had to say. The issue is that,
once again, the WAI community was unaware or felt like they were not
being given the opportunity to affect change.

It's a break down in communication on both sides. WHAT WG has not been
clear about what we require, or we haven't made it clear to WAI. There
are at least 8-10 people in WAI that are confused about why they are
being repeatedly rejected - perhaps they're emotionally tied to their
solutions, perhaps WHAT WG doesn't get what they're trying to
accomplish. Those possibilities are beside the point:

There is no easy mechanism for them to edit the specification, and until
recently, they were under the general impression that Ian was the
gatekeeper for the HTML5 specification.

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.

I hope this helps clarify some of the positions that the paper was
attempting to express. It wasn't meant as an attack on the WHAT WG - it
was meant as a feeler document to see how this community would react to
the proposed changes. That is, it's good to get feedback before I spend
the time (and money) to implement the changes (some of which we'll
conclude are unnecessary).

-- manu

[1]http://img132.imageshack.us/img132/2988/27062201.jpg
[2]http://vger.kernel.org/vger-lists.html

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Bitmunk 3.1 Released - Browser-based P2P Commerce
http://blog.digitalbazaar.com/2009/06/29/browser-based-p2p-commerce/