Comic Update: The W3C/WHATWG Community Theater Group
July 27, 2009I can’t help but be shocked at times at the drama and ugliness that builds up around the HTML5 effort. Good men and women, thinking that they can make a difference, time and again enter the dangerous mailing lists of the W3C and WHAT WG only to be ignored at best or belittled and chewed to pieces. These are zones (allegedly) of collaboration, but instead seem more at times like zones of war.
Go ahead and take a look for yourselves.
I’d think that this was just me overreacting, but when I tweeted on Sunday about my thoughts on the drama in the lists, I got a number of responses that illustrate that I’m not alone in my perception.
Jin Yang indicated that popcorn was a good snack while watching the drama unfold. After I made a bar brawl analogy, David Peterson suggested that whiskey might help them calm down, and that his two year old has progressed farther in the manners department. John Foliot provided some perspective sharing that this “us & them” mentality is a relatively new thing. And Manu Sporny joked that the W3C and WHAT WG originated as community theater groups.
Naturally, his joke was comedy, not fact. But I couldn’t help but think, what if…? So today’s comic portrays Manu Sporny and the Squirrel attending a fateful showing of Our American Cousin.
I want to say that I do see a lot of polite dialogue in the lists. I’m just amazed at how much bad behavior (sometimes well dressed, mind you) makes it into the discussions. Here’s hoping the good outweighs the bad by the time Last Call rolls around.
(As a closing note, I like the term Dundrearyisms.)
I don’t post to the WhatWG list very often, but I’m afraid the list has started causing me to behave like an asshat about somewhat trivial things. It is hard to keep an honest, compassionate, friendly front up when it feels like snark pretty regularly enters the conversation. (Thanks for helping us laugh at ourselves!)
Nicely done Kyle. As for the HTML5 spec group effort, like many other group efforts I’ve seen in the past (non tech related too) suffers from the same problem: when too many people get involved you get too many voices and directions. This essentially is a big design by committee. However, if you have one person lead it, then people would complain about that too… I think it’s good to have a clearcut vision from the very start.
As I was looking over the new HTML5 spec, I can’t help wondering about some of the new tags: what problems are these really solving?
@Eric – With people that are so motivated to create the right spec coming from such strongly opposing viewpoints, it’s no shocker that people devolve into snark at times. I can only hope that by the participants constantly reminding themselves that it is supposed to be a civil dialogue they can keep the metaphorical barbarians constantly at bay.
@Jin – It’s a huge dilemma, the many versus few approach. Considering the long-term impact and hoped-for lifespan of HTML5, it’s hard to justify keeping the decision-makers down to a few, especially considering the far-reaching consequences of their actions on fields like accessibility. At the same time, if it’s too huge there’s a serious risk of paralysis. I’m just glad I’m not looked to for the solution.
Regarding tags: I agree. Like, do we need both header and hgroup? Is aside actually useful in most cases, or merely a confusing tag that should be used much less frequently that in will be (sidebars)? I think I like section, but is it really more useful than div? So many questions come up about what is really needed.
The header/footer tags definitely drew some questions. Since I work with web apps a lot, I’m curious about the new form elements. (Mostly masked text inputs). I feel these are nice to haves, but they’ve already been implemented quite well using css/js. I was disappointed to see that TABLE hasn’t gotten any improvement. As of now, TABLE is rather useless for displaying large tabular data(many colums, rows). I’m hopeful about the new DATAGRID tag. I hope it will have many features that TABLE lacked.