Comic Update: Madness? This is HTML5!

April 13, 2009

Warning: this post falls into diatribe territory. I strongly feel that important technologies should be determined by consensus and not closed circles, and I’m not convinced that this is currently the case of HTML5.

I seriously doubt that Ian Hickson would ever kick Manu Sporny into a deep well (as today’s comic implies). For that matter, I’m not convinced he’d run around in only a cape, sandals and shorts, but I don’t know him as a person so I could be wrong on that point.

However, everything I’ve read, from the W3C’s mailing list archives, to blog posts by various people ranging from ARIA to RDFa, to Ian’s own words have convinced me that Hickson has fallen deep into a self-important gatekeeper mentality on the HTML5 spec, and anyone else’s opinions be damned. Although I will rant a bit on the topic, I’ll start by directing you to the following blog post/chronology by Sam Ruby that discusses this (albeit without the rhetoric I’d be more likely to fall into). The whole thing is a good read, but if you’re impatient you can jump to the end and check out his conclusion. He discusses the need for consensus over dictatorship in the open web again here (I get the impression he discusses that a lot, this is just a sample. I also don’t think he uses the word “dictatorship.”)

It’s become clear to a good deal of people more involved in these circles than I that a Not Invented Here attitude has tainted the HTML5 group, as discussed by Jeremy Keith here in a post about ARIA and HTML5. I’m guessing it’s an easy enough trap for any group of experts to fall into, but it still creates a situation where an otherwise open process becomes a closed loop. Case in point? Well, if ARIA isn’t enough for you, how about the attempts to get RDFa into the HTML5 spec?

RDFa has been facing a Hixie-manufactured road block for months now on inclusion into the HTML5 specification for what on the outside appears to be no better reason than its origination outside of his inner circle. Ian claims he’s seen insufficient use-cases and that he is “confused” by how RDFa is used, despite constant feedback by the RDFa proponents such as Manu Sporny providing both use cases and tutorials. Considering his technical expertise, I find the confusion claim by Hickson more than a bit perplexing. My own technical pedigree doesn’t come close to Ian’s, and yet I was able to successfully use valid RDFa syntax after less than a hour of reading the convenient RDFaWiki. Heck, if reading isn’t your strong point (which would be an unusual situation for a web professional) you can even watch videos they provide.

As near as I can tell, the only reason that he’d be “confused” by both the problems RDFa is designed to solve and how to implement it is because he wants to ensure that it doesn’t make it into the HTML5 spec, and he’s simply counting down the timer. Ian’s guide to handling people starts with Step 1: “There is No Situation” and concludes with Step 4: “Something could have been done, but it is too late.” Considering the stalemate for the past few months as he says repeatedly “There aren’t enough use-cases” or “I’m confused”, one could guess that he’s holding out until October, which according to his often derided timetable is when the Last Call Working Draft is supposed to occur.

Ultimately, though, the problem is more deeply routed than stubbornness. It seems, by all accounts, an unwillingness to play well with others. Quoted in a comment to Sam Ruby’s post Half Full, Ian said “The HTML5 work isn’t using the traditional W3C approach, and will never use a consensus approach so long as I am editor. Consensus simply isn’t a good way to get technically solid specifications, and is in any case basically impossible to achieve in a group with hundreds of participants such as this one.

Someone with that mentality shouldn’t be allowed to steer the ship for a standard that will define how millions (if not billions) of web pages are made over the next few years. We’re all going to be impacted by HTML5, so even though we don’t need to all agree (an impossibility considering human nature) at least attempting a consensus of those involved is desirable. Even if I’m frustrated by glacial pace of CSS3 implementation, I prefer the W3C’s attempt at a participatory process to some sort of autocratic decision-making on how I’ll be coding for next few years.

For more views about the challenges of trying to be involved in the HTML5 process, peruse these bits about the RDFa/HTML5 conflict by Shelly Powers. Also, I reccomend checking out the advocacy of rev=”canonical” by Jeremy Keith here and here. These posts are notable because they illustrate issues with how the HTML5 group is impacting web development (without hitting the topic over the head as I’d be inclined to do) from the angle of an easy to state problem: the prevalence of URL shortening, the potential for link-rot, and a proposed solution that includes using rev, an attribute that the HTML5 WG has already decided to remove from the HTML5 spec.

What can be done? Well, you can do as Keith proposed for rev=”canonical”, and use it, validation be damned. If, for example, RDFa or ARIA is used enough by authors, then a time will come that no option will exist other than it be included in the spec. It’s a brute-force approach, but it’s a democratic one, which is far preferable to letting one Google employee decide what’s best for us.

Respond To This Post

Share This Post With Others: |

Category: Browsers, Comic, Drama | Tags: , , , ,

9 Responses to “Comic Update: Madness? This is HTML5!”

  1. Love the comic!

    I’m somewhat in disagreement about the “NIH” mentality allegations, though. In practice, we try as much as possible to get everything from existing practice as possible. For example, all the parsing rules come from existing browsers, as much of the language as possible is derived from HTML4, the entire drag and drop mechanism is taken from IE and Safari, the selection APIs are taken from Firefox… we try as much as possible to get browsers to implement extensions before we spec them, and we look for existing technologies where that’s not possible. There’s actually very little in the spec that’s been invented as part of HTML5 itself, really.

    ARIA is to be integrated with HTML5; I’m not sure where people are reading hostility from. There certainly have been valid (IMHO) concerns about making sure the specs align sensibly, and don’t contradict each other — for example, it would be silly if we could have HTML say “this is a checked checkbox” while ARIA said “no, it’s a drop down select box”. We want to make it possible to have validators catch errors of that nature, to help authors make more accessible pages. Currently we’re primarily waiting for the ARIA group to actually define how ARIA works — the WAI-ARIA spec people have mentioned is remarkably light on detail.

    Similarly with RDFa, or eRDF, or Microformats, or the variety of other manners people have suggested we should adopt wholesale for marking up micro-data in HTML documents: we have been working for quite a long time now in trying to distill what it is that the various communities actually want in order to evaluate the various proposals we have. We can’t just adopt one of them (RDFa, say) without making sure that it does address the needs it claims to address and the needs that others want addressed. There have also been raised some pretty valid concerns, again IMHO, about the actual RDFa syntax — it is, to put it mildly, somewhat non-trivial. Manu and I in particular have been working quite productively off-list (both by e-mail and by phone) for some time now to try and get us on the same page.

    I plan to figure something out with how to mark up micro-data later this month. (Right now I’m busy redesigning the <datagrid> element after some pretty major flaws were pointed out with it.)

    HTML5′s mailing lists have over 900 people subscribed. This is a big help in preventing us from getting trapped in the closed feedback loop you mention. However, in any community this size, there are going to be people who are disappointed in the decisions. I hope, and believe, that the path we have navigated so far has kept the number of such people to a minimum.

    (Minor notes on the comics — I don’t drink, at least not yet, though I guess I might by 2022! I wouldn’t wear capes, because of the line in the Incredibles where Edna says “no capes!”. I usually wear glasses these days. Other than that it’s pretty spot on though!)

  2. I’d add a Cat to the theoretical cape, though.

  3. Ian,

    I’m glad you found it humorous! Thanks for the glasses notes. None of the images I could find to reference you included such a detail, and I try to obsess a bit about capturing someone’s image as accurately as possible (within the context of my artistic limitations).

    My concerns about micro-data formats is a today/tomorrow sort of perspective. As you’ve stated before, you’d like to handle today’s problems today. I agree that it’s a sensible viewpoint. However, considering how some things on the Internet may persist for decades, I can’t help but feel that band-aid measures like Microformats are going to create a larger issue in the future versus, say, an extensible format like RDFa. The more data that’s placed into formats with a limited shelf-life, the longer applications meant to use micro-data will have to support varying formats of varying efficiency well past their actual lifespan.

    I’ll admit, my own information about ARIA’s pace of integration into HTML5 was based largely on the posts of others on the topic, and not rigorous first-hand research. Considering the importance of improving accessibility for people with disabilities on the web, I’m glad to hear that it’s moving along more smoothly than I’d thought.

    The greatest challenge I find in accepting the open nature of the HTML5 process are comments like the one I quote about consensus. Considering consensus typically is defined as “an agreement with the majority,” it seems consistent with the way the W3C operates and the desired nature of the open web. You seem opposed to that, however. Is your open process, as you define it, one where the majority (in this case, the community of people involved in the process) are able to provide feedback, but the decision-making still resides in the hands of an individual or small group? If so, I’m not sure if it’s a method that is ultimately desirable.

  4. I expect we’ll end up with an open-ended micro-data mechanism, I haven’t gone through the use cases Manu wrote up yet. I guess we’ll see what happens later this month.

    Regarding the mechanism that HTML5 is being developed, I could reply in several ways. I could say that we are in fact using a consensus-based mechanism, where I put forward a proposal, and then the W3C working group can override it if they disagree with it (this is what the W3C HTML WG charter says the process is). I could say that I make decisions based on feedback, trying to make the best technical choices, ignoring how many people agree with any particular proposal. I could say that we are in fact using a consensus-based approach, since the draft (notwithstanding outstanding issues that I haven’t yet fixed) matches the majority opinion of the people who have sent feedback in. I could say that I am the sole editor but that I was voted into that position by consensus, and that all it would take it replace me is for someone to get a few dozen people to vote for them instead.

    All of those responses would be true. They’re all different facets of the same coin.

    It’s unclear what process you would prefer. The way the SVGWG, the CSSWG, the old HTMLWG, the XHTML2WG, the old DOMWG, the XML WGs, and so forth, work is exactly what you describe: a small group of people (representatives who are able to pay the exorbitant W3C membership fee) get to vote on what the spec should say, and the spec is thus designed by a committee of people pulling in different directions, based vaguely on public feedback. The way we’ve worked in the WHATWG is IMHO better: we have one person (me, in the case of HTML5) who explicitly takes into account all feedback, replying to all e-mail, and tries to write a coherent specification based on what people need; and to protect against that person “going rogue”, we have people who have the power to replace him (the WHATWG steering committee and the W3C working group chairs).

    We could put every single decision to vote. I make literally hundreds of editing decisions a day, typically. I’m not sure it would scale; even if we could actually pull it off, it would certainly put back the expected completion date of the project by decades. It’s also not clear that we’d end up with something technically better: design by committee isn’t generally successful.

    In practice, though, none of the above descriptions are what _really_ happens. It doesn’t matter what I, or a committee, or a big working group voting system, come up with. At the end of the day, the people who have the power to make or break the spec are the browser vendors and other implementors. I could put RDFa in the spec, but if everyone uses n3 in script blocks, RDFa won’t go anywhere. A committee could vote to put a date control into the spec, but if the browser vendors don’t implement it, then it doesn’t go anywhere and the spec is just a lie. The reality of the situation is that we can nudge the browser vendors, but when the rubber hits the road the spec has to agree with what they want, or it’ll become a work of fiction. Just look at XHTML2.

  5. (Note: In my first comment I meant to say that I was redesigning “the datagrid element”; it seems your block stripped the angle brackets around the work datagrid along with the word itself.)

  6. Ha ha! Very funny web comic, Kyle – I loved it. Your analysis of the current climate was equally well articulated. Just for the record, Ian has never tried to kick me into a pit — at least, not while I was paying attention :). Although, now that you’ve put the idea into his head, I’ll be careful to steer clear of open manhole covers, wells and ravines for the next couple of months.

    There are certainly two philosophies at play here. One of them states that standards should be built in small communities of experts with public input (W3C). The other says that standards should be built in largely public communities headed by benevolent dictators, like programming languages (Python) and operating systems (Linux). I think it’s clear that RDFa was built using the first philosophy and HTML5 is being built using the second philosophy.

    I can certainly see the benefit in both approaches and think that the most important goal for us is creating open, standards-based technology that helps make the Web a better place for all of us. The good news is that the various web communities involved in all of this have a good track record of eventually figuring things out.

    While our methods may differ, all of us have the same end-goal — to make the Web better. One of the many benefits of our ecosystem, unlike most politics, is that you can see the “web standards” sausage factory in operation.

    I’m glad that there are people like you, Kyle, that take the time to point out the humor in all of this… for when we lose the ability to laugh at ourselves, we have lost the joy in our work.

    Keep ‘em coming :)

    – manu


    Manu Sporny
    President/CEO – Digital Bazaar, Inc.
    blog: A Collaborative Distribution Model for Music
    http://blog.digitalbazaar.com/2009/04/04/collaborative-music-model/

  7. BTW, I really would be interested in what process you would prefer standards development to use. If someone comes up with a system that results in technically better specs than the various processes we have now, I’d be very happy to use it.

  8. @Manu – I’m glad you liked the comic! I agree with you that a sense of humor in what we do is important.

    @Ian – I think my blog auto-strips the majority of tags (at the very least, those it doesn’t recognize) from the comments. I’ll see if I can edit the comment to approximate your intent there.

    I’ll admit that I don’t have a clearly defined alternative to either of the processes Manu summarized, especially considering the necessity of ensuring quality technical specs. As always, it’s easier to tear down than it is to build up.

    Obviously public feedback is important to the process, even if it has a high level of noise. I think the only strong objection I have to the HTML5 system is that there’s a single decision maker at the end of the whole process. Even with a well-meaning expert in that position, there’s bound to be the slant that all individuals are victim to that will color the final result. Some sort of panel or group that share the ultimate decision-making power seems like it would be more effective in preventing that sort of situation. Granted, even a group is bound to be victim to special-interests, but they should balance out more.

    Now, that said, I don’t believe a “pay to play” situation that requires a high entrance fee is the best way to create a group that is guaranteed to be looking out for everyone, which begs the question of how such a group would be formed.

    I’m not sure. I just know I’m less comfortable when I’m at the whim of any one person, well-meaning or not.

  9. The one decision maker at the end of the HTML5 process, according to W3C rules, is Tim Berners Lee, not me. :-) I’m actually at the start of the W3C process — after me there’s the W3C HTML WG (all 300+ people), represented by the chairs (Sam Ruby and Microsoft’s Chris Wilson currently), followed by the implementors (mostly browser vendors), followed by the AC reps (one vote per W3C member company), followed finally by W3C management, represented typically by Tim.

    Does this reassure you?

    Having said that, have there been special interests that I’ve been biased towards without good technical reasoning? If so, I should address that. My goal is to make sure that whatever I write is the best technical solution, such that the subsequent steps in the W3C process have no reason to change it. In my experience, when panels or groups (or committees, as they are normally known in the standards world) have to make design decisions together, the result is usually far less coherent, and far, far slower, than when things are designed by a single person.