The HTML WG continues its endless round of argument. Like Ouroboros, it seems intent on swallowing its own tail, all of which has left me in a quandary: I can’t stand anything to do with the email lists anymore, but I really can’t sit still and let the HTML 5 document be released, as is, without at least attempting to fix problems with the document.
No, let me rephrase that: I can’t sit still and let the HTML 5 document be released without at least making comment on it. I doubt I could have any impact on the document, and I certainly don’t want to continue to be part of the never ending arguments. They depress me. They sap my energy. A vigorous discussion out at the HTML WG email list leaves me wanting to sit in front of my TV, watching old episodes of “I Dream of Jeannie”.
The Chairs have recommended that those of us who want to bring about change, should grab copies of the spec and make the change. Post the changed document out at the W3C site. Put the change up for a vote. But how would this work?
The draft of the HTML5 spec out at the W3C is under continuous change, the formal Working Draft hasn’t been updated for some time, so we’re having to make changes on the run. To actually make these changes requires a degree of technical proficiency that has nothing to do with HTML markup. We’re told that to propose changes to the document for consideration, we need to, first of all, send our SSH2 public key into the Michael Smith, who will then set us up so that we can check out the existing documents, using CVS. We will then need to use a variety of tools, SVN, CVS, makefiles, XSLT, and so on, just to get reach a point that our concerns and suggestions are actually taken seriously.
In other words, if you haven’t been a Unix programmer, be ready for some serious tech sticker shock.
Cameron McCormack provided a solution, in the W3C archives email list, to make the effort easier:
Let’s say I want to work on a branched spec. I would need to have a
Unix-y environment (so that means Cygwin on Windows) that can execute
these commands, at least: make, perl, python, svn, grep, sed, head,
patch, anolis. I would download and install Anolis from:
http://anolis.gsnedders.com/
Then, I check out the HTML WG repository somewhere:
$ cvs -d :ext:username@dev.w3.org/sources/public co html5
add a directory for my spec:
$ cd html5
$ mkdir spec-mccormack
$ cp spec-template/{*,.cvsignore} spec-mccormack
(ignore the error about not being able to copy the CVS directory)
initialise it with the current spec source:
$ cd spec-mccormack
$ make init
I’d then edit the EDITOR_EMAIL, EDITOR_NAME, EDITOR_AFFILIATION
variables in Makefile. Also, I’d change THIS_SPEC in Makefile to be set
to the directory I created (in this case, “spec-mccormack”).
Then, to build the spec and check it in:
$ make
$ cvs add Makefile header source util.pl Overview.html
$ cvs commit -m "Initial check-in."
Now I can edit the “source” file and run “make” to regenerate
Overview.html. To merge in recent changes from Ian’s spec:
$ make merge
That could fail if the merged changes are to the same parts of the
document that I’ve been editing. In this case, rejected patch files
named *.rej will be dumped out into the directory. I’d then merge them
manually, and then indicate that I’ve resolved the conflicts:
$ make resolved
The ‘header’ file is just a copy of the current document header
(everything before the ToC) from the W3C copy of the spec. The build
scripts here will modify various parts of this in the generated
Overview.html, which is a “willful violation” of the comments Ian has
included in the spec source. :-) I’m presuming this is OK since this
isn’t editing Ian’s document. Ian, let me know if you’d like me to do
less/different munging.
Also note that if you want the images in the spec
(http://dev.w3.org/html5/spec/images/) you’ll need to copy them over
yourself.
Cameron has provided a template directory, but I haven’t been able to check it out to give this effort a try. Notice that you’re checking out from both the WhatWG and the W3C directories, and then checking into the W3C directory. Oh, and if you don’t know what any of this means, well, you can ask for help.
The only problem is, having to ask for help every step of the way puts people at a disadvantage. It already creates a separation between the participants; between those who know Unix, and the magical concepts of CVS and Makefiles, and those who are experts in other things, such as markup, or accessibility, SVG, JavaScript, video controls, and so on.
Manu Sporny is aware of the issue, and has been working on an approach that would make it simpler to check in and out the documents. He just posted an email to the HTML WG that outlined how to use the GIT Repository, which does put most of the effort into the browser. Better, but still intimidating for folks who have never used source code control, sourcce code repositories, makefiles, autoconfig, and so on.
There’s nothing wrong with source code control. I like source code control. And I would expect this level of commitment from people who end up as formal co-editors of a specification, but not necessarily people just wanting to make comments, suggestions, or proposing alternative text. This reliance on source code control and makefiles is, to me, just as much a roadblock as the rest of the HTML 5 process has been, except now we’re trying to shift the “blame” if you will, to technology rather than the HTML WG, the HTML 5 editor, and the W3C.
I am a programmer. I do know CVS and SVN, autoconfig, makefiles and so on, though GIT is a new one for me. My system is set up to run Cameron’s process. I’m sure I could manage Manu’s alternative. If I don’t, it’s not because I can’t, but because I find the whole process to be absurd.
HTML is a web document markup language. It is not a programming language or operating system. It is not WebKit, the Apache project, or the Linux kernel. Why it is being treated as such is because of group demographics. The recommended processes to work through issues are symptomatic of the fact that there is little or no diversity in the HTML 5 working group, virtually none in the WhatWG group. What we have is a working group run by tech geeks: not designers, not accessibility experts, graphic artists, web authors, not even web developers. Hard core, to the metal, geeks. And to a geek, the way around a problem is to throw technology at it; the way to filter input is to use technology as a barrier.
If you have to ask, you’ve already failed the first test.
With all due respect to Manu and Cameron, and Michael Smith at the W3C, for trying to make things simpler, I’m not buying into it. Yes, I am set up to check in and out changes to the W3C directory, and I pulled a copy of the source. But I copied the documents into my space, at Burningbird. What I’m going to do for the next couple of weeks, is go through the document, piece by piece, make note of the problems I see, why I see them as problems, and modify the documents accordingly.
I’m not going to check any of it in, though. I’m not going out to the HTML WG and beg, hat in hand, to be given an audience. That ship has sailed. Have a nice trip! Bring me back a coffee mug!.
The only reason I’m doing this work, is that there seems to be a belief in the HTML Working Groups that those of us who have expressed concerns to the group aren’t willing to roll our sleeves out and get involved in the nitty gritty; that we’re not willing to to match work to words; that we’re all talk, no action; that we’re poseurs. In other words, street cred. Show you can walk the talk! Prove yourself!
I suppose I could just ignore the assumptions, and the people making the assumptions, but it really peeves me that people are using technology as a barrier. I like technology. Technology should enable, not obfuscate. And proving I have street cred isn’t the only reason I’m doing the work. There is another reason, which motivates me more: I’d like to show what my version of HTML 5 would look like, if I had my druthers. Just because.
Of course, while I’m doing this work, I have to put my book writing aside (sorry Simon), and postpone an article on SVG (sorry Carolyn). I’m also not getting paid while I do the work, because, unlike several members of both working groups, I, and many others, aren’t paid to do this work. But that’s OK. I am willing to forgo that new computer I need, or the salmon fillets and fresh fruit I like to serve a couple of times a week because they’re so healthy, and other such luxuries, because I find this whole thing to be so fun. Why else would I spend so much time on this effort, if it weren’t so much fun. Seriously, HTML could be redefined to mean “Hot Time Markup Love”.