Re: any comments on HTML charters

Hey Dean,

On Wed, 1 Nov 2006, Dean Jackson wrote:
> 
> Do you have any feedback on the HTML charter?

Sure.

Given the current situation, I think the charter should be explicit about 
its relationship with the WHATWG community and the work being done by the 
WHATWG community. (This is a group of several hundred people, several 
dozen of which are very, very active across the board, and many more 
dozens of which are active on specific topics.) Is it intended to replace 
the WHATWG community? Is it intended to closely collaborate with it? Is it 
intended to work in parallel with it? Is it intended to compete with it?

Let's consider each of these possibilities:

Replacement: If it is intended to replace the WHATWG community, then the 
WHATWG community will have to be approached and asked to stop doing what 
we're doing. For the community to want to give up and let the W3C do it, I 
think they'd need at least two things:

 * A guarentee that the work would continue in the same vein, with the 
   same priorities, same quality of work, and same speed, and

 * A guarentee that they will be involved in the work to the same level.

Collaborate: If the group is intended to collaborate with the WHATWG, then 
I think the WHATWG community would be very happy. However, would the HTML 
WG members be ok with that? Collaboration would consist of having only one 
specification, shared between the two groups, published on both sites, 
with feedback sent to both groups treated equally. This allows the spec to 
gain patent policy protection, allows W3C members to take part without 
losing face, puts HTML5 back onto the W3C REC track, and yet keeps the 
existing community happy about their involvement.

Parallel: If the group is intended to work in parallel with the WHATWG, 
developing specifications that complement but don't compete, but 
simultaneously not working with the WHATWG directly, then what is it going 
to cover? What will make its work any more relevant than XHTML2? Based on 
the current description of scope and deliverables, it doesn't seem that 
this is the intent.

Competition: If the group is intended to compete with the WHATWG, 
developing specifications that are mutually exclusive with the WHATWG 
ones, then I fear that the W3C group will not succeed. The WHATWG 
community is very adaptable; members of the community have been keeping 
track of things in XHTML2, for example, and suggesting them for inclusion 
in the HTML5 work -- in several cases, most notably the <section> element 
and headers -- the WHATWG spec version of the feature ends up fully 
specified long before the XHTML2 working group's, even though the other 
group came up with the idea first.

It seems best to me for the new HTML WG to collaborate with the WHATWG. 
However, it seems likely that the W3C would not agree to this, as it would 
basically mean relinquishing editorial control to the incumbent WHATWG 
community (with myself as editor, in all likelihood).

I have attached a proposed charter that you could use verbatim if the new 
HTML working group is intended to collaborate with the WHATWG instead of 
replacing it. This charter would be a replacement for the current proposed 
charter. It is a departure from the usual W3C working group process.

If the W3C isn't amiable to collaboration, then it seems obvious that the 
alternative is replacement. Thus, the charter would have to basically work 
to ensure that the WHATWG community felt that the new group was a worthy 
replacement. Naturally, it would probably take some time for the new group 
to demonstrate its ability to replace the WHATWG, during which time the 
two groups would work in parallel. And, it needs to be said, despite being 
obvious, if the new group failed to demonstrate such an ability, then the 
WHATWG would probably continue its work.

The rest of this e-mail therefore examines what the bare minimum would 
probably have to be to make the members of the WHATWG community feel that 
the HTML WG is an equivalent or better home for their work than the 
existing WHATWG mailing list.

The charter should require more openness. I think that working group 
membership should be open to anyone -- not just W3C members. Anyone 
wishing to join the group would have to accept the W3C patent policy, of 
course; however, the current mechanism, whereby someone can pay $900 to 
get a bigger say in the future of the Web, would clearly not be acceptable 
to the members of the WHATWG community, many of which are students, self- 
employed, or working for organisations that are not W3C members and have 
no real reason to join.

The group should not have a private mailing list -- there should only be 
one mailing list for all working group discussion, and that should be the 
same public, open-subscription list as the mailing list to which feedback 
is to be sent. Ideally, www-html@xxxxxx would fill this role. The 
w3c-html-wg and www-html-editor lists would be retired.

The group would not have face-to-face or teleconference meetings. Such 
meetings are not manageable when the community numbers in the hundreds; 
and in any case, most members couldn't afford the time or financial cost 
of attending regular meetings. All discussion would therefore take place 
in the archived, public mailing list.

The group's process would have to ensure that the quality of work achived 
by the WHATWG process is kept. In my opinion, this means having a single 
editor, who listens to all feedback (even feedback not explicitly sent to 
the group, e.g. feedback on blogs, in bug systems for Web browsers, in 
private e-mail, etc), and then writes the specification based on this. It 
means accepting that such an editor must have the final say, thus ensuring 
that the specification has integrity rather than letting it be pulled in a 
multitude of directions, becoming nothing to everyone in an effort to 
become everything to noone.

Naturally, a process would have to be in place to ensure that if such an 
editor was to get out of hand, the working group could replace him. I 
suggest that a two-thirds majority vote of the working group members be 
required to replace the editor. In practice, the WHATWG has such a 
process, but it has never been used, partly because (I assume) the people 
with this voting power have felt that I have been doing an adequate job, 
and partly (I fear) because they have nobody else to do the editing work.

The charter should acknowdedge that having a single editor with full 
editorial control, even if such an editor is entirely basing his or her 
work on the feedback from the community at large, is likely to result in a 
specification in which everyone has pet peeves. However, it should 
probably also indicate the intent, namely that while such a specification 
may not be perfect to all involved, it is likely to be an overall better 
specification than a group-edited work, where the editors don't 
necessarily feel quite the same level of responsibility for quality.

Having a single editor also goes a long way towards ensuring that the 
group's work continues at the same speed as the WHATWG. However, it should 
not be assumed that the timetable is anything quick. Here is an outline of 
how I would expect a new HTML specification to proceed along the W3C 
Recommendation track:

   First Working Draft . . . . 2007
   Last Call Working Draft . . 2009
   Candidate Recommendation  . 2012
   Proposed Recommendation . . 2022

This is not facetious. I think it is realistic to think that, even 
continuing the WHATWG work starting with the same specification that the 
WHATWG has been using, the working group will not reach a point that 
should be considered stable in less that two years. I would also suggest 
that dealing with the issues raised by the community, even if done as a 
full-time job by the working group, would still take at least a further 
three years. Finally, since reaching PR is dependent on getting 
interoperable implementations, and since that requires the creation of a 
comprehensive test suite, I think ten years for that is a reasonable 
guess, *if* the working group continues to work during that entire period 
to create the test suite. Note that HTML4, which was first published in 
1996 (ten years ago) has *still* not reached full interoperability, and 
would not be able to get out of CR today.

As the above should make clear, I agree that a test suite is imperative. 
However, the charter needs to be far more explicit about the size and 
scope of the test suite. Ten thousand tests probably wouldn't be enough to 
test for interoperability of the next version of the Web. The single most 
annoying problem for Web authors today is lack of interoperability (though 
it is usually phrased more crudely), and the charter should recognise this 
and require the group to address this head-on.

Any charter for a working group covered under the W3C Patent Policy must 
include a scope section giving a list of features and deliverables, but I 
do not have a strong opinion on what exactly should be covered here. I 
still stand behind the fundamental principles that Opera and Mozilla put 
forward at the Web Applications and Compound Documents workshop:

   http://www.w3.org/2004/04/webapps-cdf-ws/papers/opera.html

I do not believe that RDF/A fits those principles. I do not believe that 
XHTML Basic is a useful specification. I do not believe that attempting to 
shoe-horn the XForms architecture into HTML is practical. I am not opposed 
to any of those features being developed (although I feel that it is 
likely that all three will be ignored by browser vendors), but I do not 
think that it would be appropriate to have any of them discussed on an 
"HTML" working group.

I do not think that accesskey is a feature important enough to warrant its 
own line item in the charter; if that feature is mentioned, then a whole 
slew of other features should be too.

I do not think that distinguishing between the "HTML" line, the "XHTML" 
line, and the "HTML DOM" line is a useful distinction; as currently 
proposed by WHATWG, all three are merely facets of the same language, with 
an API to that language, and different serialisations of that language.

I do not think it is useful to worry about existing specifications, namely 
HTML 4.01, the various NOTEs on HTML, and the XHTML recommendations. 
Merely creating a new specification is a massive undertaking. Writing 
comprehensive errata for HTML4 would be a decade-long work in and of 
itself. It would be better to let those specifications lie while the group 
develops a new version, and the make the new version obsolete the old 
specifications all at once. (This is the model that CSS has been 
following, and it has found it to work well; with the experience of the 
CSS working group, I am confident that such a path would be successful for 
the HTML working group.)

I do not think it makes sense to explicitly mention the QASG, charmod, or 
AWWW in the charter. I was one of the first to make use of QASG, and it is 
a very helpful work, but it is no more than that, and shouldn't be so 
important as to be part of the charter. Similarly with the other two.

The list of dependencies is far bigger than required. I would remove _all_ 
the dependencies except WebAPI and XML, which are the only two real 
dependencies that an HTML/XHTML/DOMHTML specification would have. This 
isn't to say that the group won't work with other groups, but it is as 
likely to work with the SVG working group than the Microformats group 
outside the W3C. Such collaborations should be the norm, not worth 
mentioning; they shouldn't be explicit dependencies. Having explicit 
dependencies on such a large number of groups implies more about the 
groups that are _not_ mentioned than about those that _are_.

Regarding time commitments, the working group shouldn't expect one full 
work day per week per participant. In practice there are few people who 
are able to contribute that much. It should allow for any amount of time 
that the members can contribute, based purely on their available time and 
inclinations. The group *could* operate with just an editor and no other 
members (though of course that would be a very bad warning sign); its 
success should be based on whether it obtains interoperability, not 
whether it has members.

In closing, I am very happy that the W3C is considering developing HTML 
further. Regardless of whether the new group eventually collaborates with 
or competes with the WHATWG work, I am confident that I will want to be a 
part of the HTML working group. I hope you are able to take the comments 
above to heart.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'