Comic Update: HTML5′s Unicorn Heuristics

June 15, 2010

When the editor of a specification becomes openly hostile about the specification he is writing, and openly disrespectful to the duly appointed chairs of that effort, then it is time to replace that editor. This seems as rational to me as a star soccer (football for the rest of the world) player getting nasty about his team and coach.

Referencing soccer during the World Cup, see? I’m so topical.

There is no soccer occurring in today’s comic, which pokes fun at Ian Hickson, editor-for-life of HTML. It also features Miro Keller, the winner of my AEA: Seattle/Dribbble guest comic contest. There’s a washing machine and unicorn in there too. Thanks Miro, for being so patient about appearing in the comic.

The pink unicorn is an example of an imaginary solution to the issue of empty alt attributes inside image tags, one which is as equally valid as the image analysis heuristics suggested by Mr. Hickson for helping blind people understand images. See Matthew May’s related bug report on this actual situation. I’m sure if the unicorn seems too girly to you, we could use tea leaves and chicken bones.

I’d give Ian points for actually seeming to care about the visually impaired for a change, but an imaginary solution being championed seems like a really poor way to address the challenges they face. I suppose it’s arguably a step-up from claiming that table summary attributes are harmful to sighted users and that authors are incapable of writing descriptions that would be usable.

Yes, he says authors are incapable of writing useful table summaries that are non-harmful to sighted users. But, thankfully, the unicorns… I mean the image analysis heuristics will be safe and far more effective.

Competence regarding accessibility challenges isn’t something Ian needs, however. Arguably, what he really needs is the ability to accept advice on such a topic from people in the know… which ties into the issue I started this whole parade with:

I used to behave the way Ian Hickson does when it comes to dealing with responsibility, power, and making use of those when dealing with other people.

Then I turned ten.

Is that statement too caustic and pointed to belong in a standards debate? My apologies. I was just following Ian’s lead. He accuses Sam Ruby of weak leadership as the HTML chair “you just do what the more vocal members of this group want regardless of the technical arguments,” proceeds to insult either the entire workgroup or Sam again (I’m unsure of the exact recipient of “you” here) “from a technical point of view, your decisions are all arbitrary.” and “The WHATWG draft continues to exist because it’s the only way to have a specification that actually makes sense in the face of the ridiculous decisions you keep making.” and contrasts the two versions of the spec in a fashion that is more than slightly disrespectful to the W3C’s version “Easier to just add the reference in just the W3C version and keep the WHATWG version sane.”

Folks, this is all in a single email.

I’m a web developer who makes a comic poking fun at our industry in my spare time.  Ian Hickson is the sole editor of the HTML5 spec, for both the WHATWG and the W3C. As discussed ad nauseum, he is (as characterized by even those not critical of him) the Leviathan, a sort of dictator/tyrant.

If Ian Hickson wants to snap at me, so be it. I’m poking fun at him with a stick as often as I can. But if as editor he cannot speak respectfully to the chairs of the HTML WG even when they’re attempting to be civil to him, then something is wrong. If he’s openly disrespectful to the very specification that he is responsible for authoring, then we’ve got an even bigger problem.

The fiction that the HTML5 spec isn’t split is just that, a fiction. The people empowered to run this process for us have a responsibility that outweighs the responsibilities of your average web monkey. Some would say this is how specifications were always written. Perhaps so. But this specification is far more public, and far more exposed to the “authors” that need to buy into using HTML5. I know for a fact from personal conversations that many of these authors aren’t buying in explicitly because of behavior like Ian’s creating the real confusion as to which specification matters (W3C vs WHAT WG) and whether the specification will survive this rancorous process.

If the editor of HTML5 can’t even be bothered to be civil about what he’s writing without a knock-down brawl every time there’s something added or subtracted that goes against his opinion, then he needs to stop being the editor. Period.

Do I file a bug for that?

Respond To This Post

Share This Post With Others: |

Category: Comic | Tags: , , , , , , , , ,

37 Responses to “Comic Update: HTML5′s Unicorn Heuristics”

  1. So then Hixie is the editor at the WHATWG but not the W3C, and you have two actively competing specs edited by different people? Do you have any particular reason to think that the W3C version would end up being the one that’s implemented? Or that either spec would be implemented by all browsers, rather than some browsers implementing one and some the other?

  2. Ayreh, do you seriously think that Microsoft, Google, Apple, Opera, and Mozilla are going to pull up stakes and troop over to WhatWG?

    WhatWG is a loose group of a handful of people, half of whom have quit participating because of unhappiness with the whole process. It is without any legal standing, no patent policy, and no contracts among the members to ensure there’s not going to be either patent or copyright problems.

    There’s no way in heck Apple will go along with this. I doubt Google will either. Microsoft hasn’t even been invited.

    Heck, unless things have changed, the WhatWG server is based in Dreamhost and maintained by Ian. If he’s asleep and it goes down, it stays down till he gets up.

    Pretending that the WhatWG folks, and all of the relevant browser companies, are going to pick up their marbles when they don’t get their way, and just leave, is nothing more than an empty threat.

    It’s also petulant. It demonstrates that rather than want to work with other web communities, the WhatWG folks will leave in a huff, because you all aren’t getting your way.

    So go ahead: leave the W3C.

  3. It’s amazing to me that Google continues to let this guy despoil its name in public like this. Does Hixie’s contempt of the W3C reflect the posture of the company itself – because unless they do something about him, what other conclusion can we come to? If so, it doesn’t speak well for Google at all.

    Has a spec editor ever demonstrated such open hostility to the very spec he’s supposedly editing?

  4. I’m not going to join in the blaming of the problems on Ian. Ian has serious control issues, true. He has the wrong attitude and temperament to be a truly good specification editor, because he can’t control his own ownership impulses.

    But it was up to the HTML WG leadership to limit these and correct them during this last three years. They haven’t through, continuing with and including the current generation of HTML WG co-chairs.

    http://lists.w3.org/Archives/Public/public-html/2010Jun/0369.html

    If you all really want to blame something, it’s the W3C for not dealing with this situation before it has gotten so bad.

  5. I’d actually enjoy seeing some other editor (or editors) try to edit the spec. It’s a thankless job and Hixie does it way better than I would have imagined humanly possible.

  6. X, who edited the HTML4 spec? How about XHTML 1.1? RDF? Geolocation? SVG? Especially SVG 1.1?

    There are dozens of specs at the W3C also edited by teams of editors whose name you probably don’t know, because they didn’t put themselves into the position of spec owner. They just did the work, to the best of their ability.

    So, yes, editing specs is a thankless job, but people have done so in the past, and continue to do so now. And you don’t know their names, because they didn’t try to position themselves as “owner” of the specs.

  7. Shelley: However unprofessional you may think the WHATWG is, it developed the entire HTML5 spec as we know it, and can very well continue in that vein without the W3C. The only question is whether the implementers would go along with it. Apple, Google, Mozilla, and Opera set up the WHATWG in the first place because they thought the W3C was getting in the way of moving the web forward, so I don’t know why you find it incomprehensible that they’d do so again. I imagine it would depend on who replaced Hixie at the W3C, and how well they were perceived as doing *by the implementers*.

    Remember that virtually none of the complaints in the HTMLWG come from implementers, and the ones that do aren’t strongly held. Implementers are usually the ones writing no-edit counter-proposals defending Hixie’s text. Lots of them use the WHATWG and ignore the HTMLWG entirely. It doesn’t matter how many non-implementers prefer the HTMLWG to the WHATWG, because the spec is meaningless if it doesn’t get implemented.

  8. Aryeh,

    The W3C would have more impact on the standard if folks in the HTML WG were allowed to participate. But no, every decision made has to be fought — not because the decision is good or bad, but because it differs from one person’s vision.

    And the implementors forget who their customers are. Are you telling me that Mozilla, Apple, Google, and Opera, are willing to tell Web developers, designers, accessibility supporters, tool builders, CMS developers–all of these groups to go to hell?

    Is that what you’re saying?

    Is that what the WhatWG stands for? A small group of browser developers who are going to take their marbles and leave in a pout because they aren’t getting their way?

    This W3C/WhatWG schizophrenia can’t continue. The veiled threats from the WhatWG can no longer be tolerated. If it means that the W3C has to go it alone, and in competition with the WhatWG, well, all I can say is, don’t let the door hit you in the butt when you leave.

  9. Sorry Aryeh, my responses were aggressive. But, as you know, this problem has been baking for a long time, and we’re all tense and irritable.

    Something to consider is that the existence of two groups is causing the problem. If there were only one, folks would have to make it work. There wouldn’t an exit plan, people couldn’t bail if folks get into a snit.

    And the W3C is the best place for HTML5, because it has the procedures and legalities already in place, already has representation of all interested parties, and people can join, not just subscribe to an email list. The W3C _is_ HTML.

    It may seem as if this whole process is tedious and unnecessary, but HTML impacts on more than just the browser companies. I don’t know what it will take, though, to get the browser companies to stop acting so, well frankly, arrogant about the HTML5 effort. I can’t believe the browser companies really want to come across so antagonistically to the very people they’re dependent on.

    Anyway, I’ve monopolized the Squirrel’s comments enough. Sorry Kyle.

  10. Browser makers should vote or agree on which spec author they wish to follow. Simply.

    They’ve done it when they’ve decided to follow WHATWG instead of XHTML2.
    They should do the same now : choose WHATWG or W3C.

  11. @shelley:

    > “The W3C would have more impact on the standard if folks in the HTML WG were allowed to participate.”

    The problem is most HTML WG “participation” is focused on pointless arguments over process/charter issues and trivial re-wordings of bits of the spec. I don’t think it’s a coincidence that all the folks doing this are W3C-heads/XHTML-fans, either.

    > “The W3C _is_ HTML. ”

    The W3C _was_ HTML. As Eric Meyer put it 4 years ago:

    “Let’s be frank: a whole lot of people who believe passionately in the web’s potential and want to see it advance fought for years to make that happen through the W3C, and finally decided they’d had enough. One by one, I saw some of the best minds of my generation soured by the W3C…”

    http://meyerweb.com/eric/thoughts/2006/08/14/angry-indeed/

    Most of the technical discussion about HTML5 is taking place on the whatwg list. The only way to make the whatwg wither away is for the W3C HTML WG to focus exclusively on any technical changes required to get HTML5 to LC asap. That’s not happening.

    @Kyle: Your comments about Ian’s alleged disregard for accessibility are, what I’ll politely term, a somewhat partial misrepresentation. We’ve been through this before.

  12. Shelley, keep in mind that feedback in the WHATWG is not just accepted but welcomed. Hixie personally responds, basically line-by-line, to every e-mail sent there (in far more detail than the chairs give on public-html). The implementers know who their customers are and are very interested in listening to them.

    There’s a big difference between listening and taking orders, though. Anyone can comment in the WHATWG, and Hixie *will* listen to them. He might disagree, of course. In that case, they can appeal to implementers directly. The implementers might agree with Hixie. In that case, yes, you’re out of luck. But it’s not like non-implementers can’t give feedback in the WHATWG. I’m not an implementer — I’m a web developer, one of the people you imply the WHATWG tells to go to hell. I’ve given plenty of feedback in the WHATWG, much has been accepted, and I’ve been given reasons for the feedback that hasn’t been accepted (although I don’t always agree with the reasons).

    There’s not really much difference between the HTMLWG and the WHATWG in this respect. In the WHATWG, Hixie considers all feedback and makes his decision, and if you disagree, then tough luck. In the W3C, the chairs consider all feedback and make their decision, and if you disagree, then again tough luck. The difference is only who makes the final decision (Hixie vs. Maciej/Sam/Paul), and how much paperwork is necessary to trigger it (lots in the HTMLWG, none in the WHATWG).

    I agree that it would be better if there were only one group working on HTML. I also agree that the W3C has some clear advantages (mainly the patent policy). However, the W3C has a number of disadvantages too:

    * Subscribing to public-html is quite tedious, requiring you to fill out forms and be manually approved and not be employed by certain types of organization, while subscribing to whatwg@whatwg.org is very simple.
    * The W3C’s rigid specification track isn’t well suited to large, constantly-changing specifications. The existence of Working Drafts as random snapshots of Editor’s Drafts is confusing, and the need for the whole draft to progress to Last Call and so on at once makes it unclear which parts are actually stable in practice. Splitting up the draft only helps here so much.
    * The decision policy is incredibly cumbersome. Even most W3C Working Groups have far simpler decision policies. As far as I can tell, usually there are only a handful of actual members (mostly implementers), and they can just have a quick vote to settle any dispute. If you aren’t employed by a W3C member organization, or among the very small number of Invited Experts, you generally have no actual say. This parallels the WHATWG a lot more closely than the HTMLWG.
    * As a result of the cumbersome processes that the HTMLWG has, which anyone on the Internet can trigger, public-html spends a lot of time arguing about process rather than substance. There are few process arguments if there’s no real process.
    * Also because of the nature of the Decision Policy, philosophical disagreements constantly crop up on public-html and are rehashed endlessly, although they’ll never be resolved. This inhibits progress on specific issues. An organization where the group in power is more homogeneous, like the WHATWG or most W3C WGs, can quickly dismiss any suggestion predicated on premises they don’t agree with.

    Most of these problems are fixable in principle. Actually, most could be fixed just by scrapping the Decision Policy and replacing it with a much simpler process that lets a small group of people decide things by applying their own judgment. Another alternative is to simply scrap the HTMLWG and have the WHATWG make up its own patent policy. Still another is to scrap the WHATWG. Which of these happen, if any, is out of my hands. In the end, the implementers will vote with their feet, and the rest of us have no direct say whether we like it or not.

    My personal take is that the W3C has grown too large and bureaucratic to be efficient. There’s too much red tape and process, and that slows down standards work needlessly. The goal of standards should be to ensure that all implementers implement the same thing, nothing more or less. You don’t need process for that: you just need a document that all implementers agree on, and how you produce that document is immaterial. Implementers are not stupid, and they will seek outside input as much as possible of their own accord. Dictating standards from an ivory tower does not work — that’s the lesson of XHTML 2.

    But I should really set up my own blog if I want to write posts this long . . .

  13. Mattur, the group is focused on process because the existing HTML5 editor refuses to consider the interests of individuals outside of the Implementers, as he refers to them. The whole process issue came about because he would use idiotic rationales for marking bugs as WONTFIX. He won’t work with the group, and demands total and complete control over the specification.

    None of you would tolerate this in your jobs, and in your projects, but you nod your heads in agreement at what’s happening with Ian. Let’s let Ian and a few browser company representatives determine what is the next generation of the web. Oh, we don’t need requirements. And we really don’t need input from people who Ian doesn’t respect, or doesn’t like. That last one is a real kicker, too, because it is almighty easy to get into the “Ian doesn’t like this person” category.

    Aryeh, the web has progressed because it is built in stable technologies. Do you think the vast majority of the web is based on cool new features, and hot new elements and capabilities? No, it’s built based on technologies that have been around for years, are stable, mostly secure, work for most of their clients, using most of their machines and software.

    This is the reality of the world. Regular web developers and designers have to work with what’s stable, not with an ever changing landscape of specifications. It may not be fun, but it’s real.

    The web has grown to what it is precisely because of standards organizations such as the W3C. No, the W3C not perfect. Frankly, I’m unhappy that the W3C has allowed this WhatWG/W3C and Ian’s nonsense go on for as long as it has. But leaving and starting up your own organization isn’t going to fix the problems that are in the W3C — just going to start them all over again somewhere else.

    And that somewhere else is not going to be better than the W3C. I have read through most of the emails in the WhatWG archives dating back six years. The only thing exceeding Ian’s arrogance is his capriciousness. All you have to do is tickle his fancy and pow, it’s in the HTML5 spec. You don’t have to provide good use cases, a decent set of requirements. No, all you have to do is appeal to Ian’s ego, or his whimsy.

    Do you really think this is superior?

    The HTML5 spec at the WhatWG crashes most browsers that open it. It’s disorganized, badly written, with no test cases, mostly unimplemented by the browsers, with few requirements trails to justify the huge number of new elements — most of which are causing a lot of confusion, even before they’re implemented.

    Do you seriously think this is superior?

    The goal of specifications are to meet real needs, first, then to ensure that the implementation is standard. How can HTML5 meet real needs, when many of the people working for the browser companies in the HTML5 spec effort seem to absolutely loath the browser customers. Yes, all you have to do is follow the WhatWG IRC to see that these developers absolutely despise us. The only people they like is people like themselves.

  14. Sorry, grammatical typos abounded in last comment. Aryeh is right, maybe longer comments should be in a weblog post.

  15. @Shelley & Aryeh – Don’t apologize for long comments. Any form of feedback and conversation on whatever topic I’ve sunk my teeth into is welcome. I certainly get far more information about the merits of the WHATWG versus the merits of the W3C than I’d otherwise easily access elsewhere.

    Frankly, my concern is less about which group is better (although I do care about that) and is more about the behavior from the top. Leaders should meet certain standards that the unwashed masses don’t. I don’t care how brilliant Ian is, he shouldn’t be badmouthing such an important effort that he is so centrally empowered by.

    @Winston – I think your question regarding Google’s condoning of Ian’s behavior by default through silence is a good one. I wonder who I’d have to poke with a stick to get a comment about that.

  16. Shelley, most of the elite technical people I respect IRL or on the web – e.g. you, Ian – are prickly as hell, suicidally undiplomatic and utterly convinced they’re right about everything. I think it goes with the territory.

    FWIW I think Ian’s, er, disregard for social-niceties ;) is sub-optimal. But at this point, I’m so frustrated with the glacial progress of web markup since 1997, I don’t care if he tells the w3c to go fuck itself and publishes HTML5 in limited editions by personally carving it into the skins of dead baby seals. Or ex-XHTML2 WG members. Using Princess Diana’s hipbone. While stamping on the Dali Lama’s spectacles. On stage. On fire. In front of the Queen. Just get it out.

  17. I’ve been called prickly by others, Mattur, and so must be. I don’t claim to be right about all things, and sorry I give that impression. Undiplomatic–yeah. And yes, it has hurt my career, both writing and consulting.

    I have a question for you in response to releasing HTML5: what do you need to do that you can’t do now, and that only HTML5 can provide?

    Me? I like the audio and video elements, SVG/MathML in HTML, the Canvas element. I also like the drag and drop, though would like it be accessible. Same with Canvas.

    I like that the browser companies have finally standardized the DOM Level 0 stuff, though it has no place in an HTML document.

    I like that tabindex has been standardized. It was left in a muddle in HTML4.

    I like these things that are part of HTML5. And none of these things are being held up. I guess that probably explains that I’m not so desperate to see HTML5 spec released. At least, not until it’s significantly cleaned up. And we’re comfortable that it’s in a state we can live with for a long time.

    You are anxious to see it released, and I can sympathize. Yeah, the process discussions are a pain. I agree with that. But I’m curious: what capability can a release of HTML5 provide that you don’t already have now?

  18. @Mattur,

    the observation that there are more process discussions in the W3C WG is correct. But please do not confuse cause and effect.

    I’ll also note that in a separate activity, the websocket protocol, exactly the same problem surfaced, in this case between IETF WG and WhatWG. There’s a pattern here.

    Julian

  19. I’ve been waiting *15 years* for . I can take the despair, it’s the hope I can’t stand.

  20. *figure*, goddamit, *figure*. The entire interwebs is against me.

  21. Angle brackets are such a pain in comments.

    Figure, eh? Well, nothing stopping any of the browsers from implementing figure right now. There will have to be a couple of implementations before CR of HTML5, anyway.

    Of course, the execution is going to be a little trickier than plopping words into the spec. I expect a lot of confusion about, and additional work related to, figure–especially to make it accessible.

    As for the topic that triggered Kyle’s post, well, I guess we’ll see what happens.

  22. Shelley, Ian listens to everyone. He might respond dismissively, but he does read and respond to every single post to the whatwg list, and every single bug opened. Even when that results in incredibly long posts that probably take days to write:

    http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-April/014372.html

    There’s an important distinction here between ignoring people, and overruling them. Hixie does the latter often, but the former never. He’s even implemented things you suggested, like (although he later reversed that after others objected). He’s overwhelmingly rejected your suggestions, but that’s because he has basic irreconcilable differences with your approach to the standard, not because he’s not even considering what you say.

    As for the success of HTML5, I think the facts speak for themselves. HTML was in complete stasis for all practical purposes from 1997 to 2004, and this is directly due to completely wrong-headed thinking by the W3C administration. The WHATWG was formed in 2004 and moved HTML forward more in a year than the W3C had in the preceding half-decade. It took only three years for the W3C to realize that they had to cave to the implementers’ approach (by forming the HTMLWG to work on HTML5 according to the WHATWG’s basic spec-development philosophy) or become irrelevant.

    Essentially all progress made in HTML5 has been due to the WHATWG’s method of Hixie writing stuff that he thinks sounds good. The W3C has to this day contributed almost nothing to the spec for practical purposes. It’s changed only tiny bits and pieces, and none of the changes so far have any effect on how the spec is used in practice. Like the image recognition paragraph that Kyle so disparages — which was one paragraph in a huge spec that imposed no normative requirement on anyone.

    Whatever objections you may have to the WHATWG’s modus operandi, it *works*. Which is more than can be said for the dysfunctional W3C procedures that gave us XHTML2.

    Kyle, yes, Hixie is not an ideal editor. He’s just very close. ;) Like a lot of techy sorts, he doesn’t always get on well with people, and is often way too blunt and confrontational. But let’s look at his direct contributions as an actual spec editor. Just for starters, consider the full text of what Hixie has written on HTML5-related things so far. With cross-references and post-processing and everything, it’s over 5 MB:

    http://www.whatwg.org/specs/web-apps/current-work/complete.html

    (Warning, ludicrously slow to load.) Even if you only use the source text, it’s still over 4 MB of text:

    http://svn.whatwg.org/webapps/source

    Now, what can we compare this to? How about, say, the entire output of the CSSWG over the course of its entire existence? There’s a handy list here:

    http://www.w3.org/TR/#tr_CSS

    Copy-pasting all the URLs into a file and running “(for URL in `cat css-specs`; do curl -s $URL; done) | wc -c”, I get less than two megabytes. Now, okay, a few of the specs are multipage, like CSS 2.1. The text version of that still adds less than a megabyte. Granted that there might be some other big multipage ones I don’t know about, and also bytes aren’t a perfect way to measure spec size, and things other than size matter (more on that later), but to a first approximation:

    Hixie has written more spec text in the last five or six years than the entire CSS Working Group combined has written since it started in 1996.

    Oh, and by the way, that’s not a fair comparison. Because by far the largest (and also probably most successful) CSS spec, CSS 2.1, was co-edited by a certain individual by the name of Ian Hickson.

    Okay, now, you might object that this is because HTML5 is unreasonably wordy. But let’s remember that while HTML5 is much more wordy than other specs, practically all of that is normative text. It’s not repetitive or redundant. The spec is painstakingly detailed, because painstaking detail is what you need to get interoperability. Most W3C specs are extremely vague, which leads to browsers disagreeing on corner cases all over the place.

    If you follow www-style, you’ll know that it’s a very regular occurrence for a CSS implementer to say “Hey, browsers disagree on rendering this, and the spec doesn’t say what to do. What do we want it to say?” When it comes to HTML5, this practically never happens. An implementer might say some spec text is a bad idea, or be confused about what the spec says, but in practically all cases, the answer *is* explicitly specified if you look. This is a very good thing.

    Let’s also note another difference between HTML5 and most specs. It’s not that hard to make up new features. It’s harder if you pay as much attention to detail as Hixie does, but you still have a lot of freedom. But large parts of HTML5 aren’t made up. They specify behavior that is constrained by legacy documents, which has never been specified before. They’re painstakingly reverse-engineered from existing browsers, mostly by black-box testing. And they actually do match behavior well enough that browsers are willing to implement them (see, e.g., the text/html parser). This requires much more effort and skill than just writing regular old specs.

    Most if not all of this reverse-engineering was done, of course, by Hixie. I wasn’t around back then, so I can’t say much for sure on who did what, but you can read some of his blog posts on it, like and the next few newer ones.

    On top of that, let’s look at feedback. As I noted above, Hixie responds to everything. Really, everything. Now, he might totally disagree and outright reject the request, but this is still way better than most spec editors. You will always get some kind of response.

    Basically, if the HTMLWG fires Hixie as editor, it will die. He’ll continue work in the WHATWG, and he’ll drastically outpace any editors the W3C can find to replace him, in timeliness and spec quality. Everyone will abandon the W3C spec in the end as a result. If the HTMLWG crosses Hixie enough to get him to quit, the same thing will probably happen. The only thing that will prevent that is if the implementers refuse to use his specs on principle, and that’s not going to happen. That’s my prediction — you can call me on it if the time comes.

    Now, you might say that dictatorship is unequitable. Maybe, but it works very well. A core part of the reason for why the WHATWG has gotten so much done is precisely because there’s someone with the power to *get* things done. By contrast, look at how the CSSWG has spent months arguing about issues like how to spec the px unit, or what to do about the obvious problems with vendor prefixes. It’s nobody’s responsibility and nobody’s right to resolve the issue promptly, so it’s not. (I’m not picking on the CSSWG here, by the way — it’s just high-profile and I’ve subscribed to www-style for a few years.)

    But perhaps the dictator will make worse decisions than a group? Not really, if he’s competent (and no one has ever accused Hixie of being anything less than competent). In cases where there’s an obviously correct answer, it will win in any event. Where the answer isn’t so obvious, and you have conflicting points of view *even after* extensive discussion, you have two choices. Either pick a position and go with it, or argue about it endlessly and still wind up with something not everyone is fully happy with. There’s no reason to think that committee give-and-take gives a better answer in the end than just having some arbitrarily-selected smart person think about it and go with something. But the latter is a lot faster.

    In the end, the goal is getting a good spec. What process is used to achieve that goal is a purely pragmatic issue. As judged by real-world (interoperable) implementation and adoption — which is the only good objective, pragmatic metric for evaluating a spec’s success — the WHATWG’s process has been drastically more successful than the W3C’s. If the W3C is unwilling to accept that, it will become a victim of natural selection, like it or not.

    (I really need to get my own blog to post this kind of thing on.)

  23. Aryeh, Ian himself has said he doesn’t read many of the email threads at the HTML WG, and this group is just as essential as the WhatWG.

    He is extremely capricious in his decisions. He’ll add something to the spec based on a causal remark from one person (see atom), and yet won’t make an edit requested by entire groups (summary attribute in table comes to mind, and I won’t even get into Microdata).

    He rarely provides a good, solid rationale for his decisions. As Kyle has noted, he’s openly disdainful of the W3C, and the HTML WG co-chairs. Well, Sam and Paul.

    CSS 2.1 was edited by a group of people, of which Ian was one. I believe that Ian could be a good co-editor, but I think he has control issues when he’s the sole editor. And a spec is better with multiple editors, because each can copy edit the others. You can’t easily copy edit your own writing.

    I agree that much of HTML5 is from legacy implementations, including the browser context section. However, much of HTML5 is new, or modified, and though some of these changes have traceable roots (no one denies all of us wanted video, audio, and canvas), much of it doesn’t. Heck, much of the new forms material was created in the original Web Forms 2.0 document, and it was created by a self-selected group of people participating in a private email exchange six years ago.

    I don’t believe the HTML WG wants to replace Ian. I think the co-chairs are bending over backwards trying to make things work with him. However, I also believe that at any time, there is a real possibility of some confrontation and Ian will leave, taking his marbles with him.

    If he does, the W3C effort will survive, most likely with a team of editors. Though Ian may be faster, that doesn’t mean he’ll be better. More importantly, there are companies who are not going to be comfortable depending on a group which is so elitist, exclusionary, and without any legal standing.
    trol.

    In the end, a good spec has to be technically good, true, but it also has to be comprehensive, inclusive, and meet the needs of all HTML communities. I don’t believe these are goals that Ian shares.

  24. I wanted to continue a second comment, but this time focusing on some comments you’ve made about the W3C.

    You mention most W3C specs are vague. Actually, most are not. What they don’t do is minutely control every last aspect of an implementation. I believe it was Brendan Eich, he of the original WhatWG core group, who said that much in the HTML5 is over-specification. He was right, there is a massive amount of over-specification in that document.

    But again, that’s the control issue that Ian has some challenges with.

    I strongly disagree with you that the W3C members have not contributed to the spec. I think that’s dismissive of most of the people’s efforts, and I think you give Ian far too much credit. In addition, if we had more editors, the W3C would contribute more, and frankly, I think the spec would be stronger, better, more clear and concise. Ian is, at this time and in my opinion, more wall than door.

    As for Ian responding to things, you’re jesting, right? Why do you think I had all my change proposals at once? Because Ian blew off the bugs for months before responding, and then responded all at once with rationales that were, well, incomplete, and bordered on the petulant.

    I’m glad you respect him. I can respect his good qualities, but I think he would be better as one of a team of people. I don’t believe he makes a good “dictator of HTML for life”. I’m astonished at anyone being so arrogant as to think of themselves as such, and even more astonished that people who supposedly have good technical backgrounds would actually encourage such behavior.

  25. It’s really kind of sad that all that text boils down to is “well, he keeps the trains running on time.”

    What I see when I look at the WHATWG is a group that wants nothing from W3C but its imprimatur. Because without it, HTML5 is not a standard: it’s just a spec. Not even that, really. It’s just a roadmap.

    Let’s look at this heuristics issue for an example of how this system “works”. I originally proposed this change through the Protocols and Formats WG (which deals with accessibility across W3C WGs) in May of 2008. It was eventually raised as ISSUE-66 in January of 2009. There were hundreds of emails on public-html about this issue, all of which boiled down to Ian vs. everyone who does accessibility work for a living. It made it all the way through the byzantine HTML WG Decision Process to a final decision which, again, saw Ian standing alone in opposition.

    Getting that one sentence removed took SEVENTEEN MONTHS in the HTML WG. In all that time, Ian failed to provide any evidence whatsoever for leaving the text there. (Surely he will now chime in and say that neither did I, and there’s one of the problems: one person’s evidence is another’s edge case is another’s irrelevancy. The only difference here is that Ian is the sole arbiter of Right and Wrong.)

    And here’s the kicker: It’s _still_ in the WHATWG document. Ian went so far as to deride it as a “political” decision in the WHATWG document’s front matter. I know this looks petty, even quixotic. But I am certain a reasonably objective third party would evaluate the arguments presented here and find that the text in question didn’t belong in the spec. If it takes a year and a half just to get that kind of fair hearing, what hope do we have of dealing with the many more glaring faults in the spec that are queued up for debate?

    Look, I want canvas and video and datagrid (oops! Never mind!) and Web Sockets and new input types and offline support as much as the next guy. The difference is, I’m not going to hold my nose when I see obvious accessibility flaws being introduced in the process, because I also happen to be one of the guys who gets to clean those messes up. So far, the reaction of the editor to those kinds of problems has been nothing other than intransigence. If I were to see even the slightest willingness to give considered thought to those issues, hell, I might be willing to throw the W3C overboard myself. But instead, here we are, fighting like dogs over some stupid editorial throwaway comment.

    This might be going swimmingly for WHATWG folks. But outside of that, try making a difference regarding this specification and see how far it gets you.

  26. Shelley: Indeed, he doesn’t reply to all threads on public-html, but he does consider all bugs in bugzilla, which, AIUI, is the way technical feedback should be brought forward in the HTMLWG.

    Matt May: You mean that keeping a sentence that allows user agents to use OCR on images if there’s no alt text (which is all too common in the real world) is *bad* for accessibility? That sounds a little backwards to me.

  27. @Ms2ger:
    a) That wasn’t the original text. What I originally objected to was much more nebulous, and in a place in the document where it looked like a reason authors could just leave alt out.
    b) I’m not saying OCR would be bad for accessibility. It might help, in some circumstances. But as a suggestion to user agents, without existing implementations, it has no place in a spec. In fact, if anyone other than Ian had proposed that text, it would undoubtedly have been rejected. It’s just bad, unnecessary editorial text.

  28. Shelley, Ian doesn’t read all HTMLWG posts, but he reads all HTMLWG bugs and all WHATWG posts (since the WHATWG mailing list serves as a bug tracker). He can take a few months to respond to things, because he responds in batches, but he does respond to everything. He does provide rationale when asked, but you think it’s unreasonable and insufficient for the same reason he thinks your issues are frivolous — you see things very differently.

    I strongly disagree that HTML5 is overspecified. It is as detailed as it needs to be, which is to say, specified to the last detail. Other specs are far vaguer, and interoperability suffers greatly as a result. For instance, take a look at this www-style thread:

    http://lists.w3.org/Archives/Public/www-style/2010Jun/0349.html

    box-shadow in CSS 3 is defined at http://dev.w3.org/csswg/css3-background/#the-box-shadow. Shadow-drawing in HTML5 is also defined, for canvas, at http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#when-shadows-are-drawn. Compare the precision of the descriptions. Now look at these two images comparing WebKit’s and Firefox’s box-shadows:

    http://www.bradclicks.com/cssplay/blur_100px_webkit.png
    http://www.bradclicks.com/cssplay/blur_100px_firefox.png

    You can verify yourself by going to the data URL

    data:text/html,!doctype html
    div style=”width:200px;height:200px;margin:50px 500px 50px -208px;-moz-box-shadow:250px 0 100px black;-webkit-box-shadow: 250px 0 100px black;”/div

    with angle brackets inserted at the right places (to avoid the angle-bracket-eater I suspect is present). By contrast, take a look at how they render canvas shadows at, say, http://www.robodesign.ro/coding/canvas-primer/20081208/example-shadows.html. Pixel-perfect identical. That is not “overspecified”, that is what standards should be — the same markup generates the same results.

    Some W3C people absolutely have contributed to the spec in the W3C. However, those people could just as well have contributed in the WHATWG. The actual changes that the HTMLWG made that Ian didn’t support (and which therefore would have not happened at the WHATWG) are not significant at all, certainly not compared to the size of the spec.

    Matt, that text is an excellent example of something that makes no difference in practice. At worst it was mildly misleading, which isn’t a big deal since practically no one would read it (certainly not typical authors). It imposed no implementation or authoring requirements, and its removal is unlikely to have any detectable effect on anything. It is not an “obvious accessibility flaw”, because even if it was wrong, there’s no reason to think that it would actually hurt accessibility anywhere.

    This is the kind of thing that WHATWG supporters get fed up by — significant amounts of HTMLWG time getting taken up by something that makes no difference in the end anyway. It’s why more than one implementer uses the WHATWG list instead: much higher signal-to-noise ratio.

  29. (You also have to change the smart quotes back to normal ones in my data URL above, once that gets approved.)

  30. And here we have an example of why Ian is not a good choice as “HTML Dictator for Life”:

    http://lists.w3.org/Archives/Public/public-html/2010Jun/0525.html

  31. Aryeh, your response is inconsistent.

    You say the HTML5 specification is not over-specified, but Matt’s example is a perfect demonstration of an overspecification.

    We don’t need to tell user agents that if they have image recognition software, it’s ok they can use it. Especially since we took pains to demonstrate how inappropriate this type of statement is, when discussing it as a workaround for missing alt text.

    The spec is full of crap like this. A specification’s job is provide a precise description of that which it controls. No more, no less. Yet there’s crap in the spec where Ian is telling the web page author what to actually put in as _content_, not as markup. Unbelievable.

    Unless we want to make something an error or warning, we have no right to tell people what to do or not to do, especially when it comes to what they provide as content material.

    As for his rationales, look at some of them (this will trigger comment hold):

    http://www.w3.org/Bugs/Public/show_bug.cgi?id=8118#c11
    http://www.w3.org/Bugs/Public/show_bug.cgi?id=8552#c15
    http://www.w3.org/Bugs/Public/show_bug.cgi?id=8818#c1

    And I could go on. Now, what useful info is in these rationales? “Um, these are good things” is about what they boil down to,except for the last one, which is a snarky aside about another bug.

    What use continue these discussions, though? We’ll never agree. You think Ian walks on water, and I think his actions, and the W3C’s tactic permissions to continue such actions, are going to ultimately sink HTML5 as a standard for all web communities.

  32. Aryeh, in your experience how are changes that come from the w3c Decision Process discussed in WHATWG? My perception is they’re not at all, Ian just decides one way or another and if he doesn’t like it he just keeps the WHATWG copy of the spec unchanged.

    I don’t know because the WHATWG mailing list archive page vexes me.

    For example, was there any discussion at the WHATWG involving any of the splits from the W3C copy of the text?

  33. (In other words, I’m trying to understand if “process to converge the specs” is equal to “convince Ian”.)

  34. Mark Morgan: the W3C HTMLWG is mainly used for intensive bikeshedding exercises spanning SEVENTEEN MONTHS or more, and, as you mention, shuffling words from one file to another. Should the HTMLWG ever decide to discuss something important, I expect it would be discussed on the WhatWG list too.

  35. Mattur, that doesn’t answer my question. Let me put it this way: if Ian doesn’t think something should go in the WHATWG spec, it doesn’t go in it. Full stop, no recourse, the people subscribed to the mailing list don’t have any recourse save not adding it to their software if they’re implementers. Am I correct?

  36. On reread, that seems a pretty random derail. I’m trying to understand how it would be possible to change the WHATWG copy of the spec due to a decision by the w3c, if that decision contradicted what Ian thinks is best. Am I correct that “merge the specs” at this point means either “convince Ian” or “change the w3c spec to duplicate the WHATWG spec? It seems that way.

  37. Never mind. The latest discussions on the WHATWG mailing list cleared everything up for me, depressingly.