Posts Tagged ‘ian hickson’

In Soviet HTML5…

Wednesday, August 29th, 2012
CSSquirrel #97: In Soviet HTML...

Today’s comic features Mat “Wilto” Marquis (Internet folk hero) in a nightmarish world that I imagine Ian Hickson envisions if HTML were ever allowed to slip from his hands and be created by the common man.

We’ve discussed the issue of responsive images in HTML and the proposed <picture> element before, you and I. Here’s a look back in case you need a refresher. It’s a bit cheeky. I get worked up over things like one smart person thinking his brain is more efficient than the combined powers of dozens of smart people.

<Picture> has had a rough road.

All the way back in December 2011, Bruce Lawson posted this idea for how the syntax of <picture> might work. Several people started a community group chaired by Mat Marquis back in February (based on a WHATWG email suggesting such) to push the idea forward so it could see eventual adoption into the HTML spec. They did a great deal of good work to make a workable, problem-solving piece of markup. Scott Jehl even created a polyfill script to provide support for the proposed markup until browsers implemented it, which you can find here.

Then Hixie stepped in. It’s been well documented in the past before, so I’ll summarize: he decided to ignore the community group and efforts of the developer community and went with srcset. Classic Hixie solo action. Here’s an aptly named summary, WTFWG by Tim Kadlec, and a piece on A List Apart by Mat Marquis.

Developers were mad. Developers were vocal. Then for the most part, the web moved on.

If it wasn’t for the continued effort over the past several months of people like Mat, that would have been that. But he and others didn’t stop, and they kept on pushing, and wouldn’t you know it? Something came of it.

Not in the WHATWG, of course. Someone hoping for that sort of miracle would be essentially signaling to everyone that they finally lost their last marble. (Here’s an example of how things were going over there, AKA, Hixie’s got his blinders on like normal.)

But over at the W3C, Mat and his allies accomplished this: an official w3C Editor’s Draft of a proposal for HTML Responsive Images Extension, featuring both srcset AND <picture> to be included into the HTML5 spec. It’s just a step, but it’s a fairly big one, and a great deal of validation for the developers that worked so hard, despite Hixie’s best attempts at ignoring them, to create a responsive image solution that works for them.

I could tell you how it’s a heroic accomplishment that is leading us towards a better web. But I won’t. Not because I think it isn’t (it in fact is!) but because Marc Drummond already said it better. Go read his article Responsive images, the picture element and the W3C: This is how you deal with Hixie and WHATWG. It’s worth it.

It’s hard to say if <picture> will ever make it into the browsers. The browser makers are mostly (but not entirely) involved in WHATWG, and would prefer to work around the W3C. But I do believe that enough community effort will continue to build on the success that Mat and the others have brought us.

I asked Mat about what he saw as the future of <picture> in light of these recent accomplishments, and what interested developers should do to help. Here’s his response.

I totally stand by that follow-up tweet I posted earlier ( http://twitter.com/wilto/statuses/240486846801514498 ): no matter how things play out from here, the dev community has done something that I don’t believe has ever been done before. You just don’t see specs – proposed or otherwise – with a developer’s name at the top. If nothing else I hope this marks the beginning of that, and that it leads to we authors having a voice in web standards equaling that of the vendors.

To get involved, more folks should join up with the RICG! http://www.w3.org/community/account/request

Let’s not waste the opportunity this has given us. We’re the developers that will have to work with the spec that’s being created, and will be answerable to the clients and site visitors that will use the sites we create. We should and can have a bigger voice in the direction of HTML. What Mat and others have done is show us how.

HTML: A New Standard

Thursday, May 17th, 2012
CSSquirrel #94: HTML: A New Standard

In the past couple days far more eloquent people have spoken about the current srcset “fiasco” with calmer voices, analyzing the situation with a maturity and fairness that frequently escapes my grasp when I’m hastily penning a post and drawing a comic.

If you haven’t read them already, I would ask that you take some time to read Jeremy Keith’s Secret Src and Jeffrey Zeldman’s The Unbearable Lightness of HTML5. I don’t think either pretends to be a neutral moderator in this debate between the WHATWG’s methodology as practiced versus the appeal of angry developers for the “users before authors before implementers” priority that the WHATWG preaches. But at the same time they clearly make an effort to understand the motivations of Ian Hickson and the browser makers, mention the merit of their position where it exists, and treat their intentions with some reasonable charity.

They also do a good job of explaining a complex situation in comprehensible, non-combative terms.

I personally don’t do well with the sensations of helplessness and the apparent disregard that Hixie and the browser makers seem to show towards developers by the WHATWG’s process. I don’t believe that ends justify means, and I personally believe that something as central to my career (and to something quite central to the Internet’s functionality) as HTML deserves stewards that are trustworthy and fair.

Idealistic, I know.

Middle Child

We, the developers, are the middle child of this whole standardization process. Unlike the users, who could care less about HOW a website works as long as it works, or the browser makers who have the power to decide how to implement the features of the Internet to meet their corporate goals and to fill their coffers, we developers (authors) are answerable to the ability of users about what they want (or need) in a website but have no power to guarantee that the browsers meet our needs as creators.

As antagonistic as our relationship can sometimes be with users, the fact is that we know we have to answer to them. If a site doesn’t meet their needs, they move on. They have that choice, that freedom to type in a new URL and get their news/lolcats/gossip/pictures from somewhere else. There are literally billions of web pages, and thousands if not hundreds of thousands of developers willing to replace us and to feed the users’ wants and needs.

When it comes to our needs and wants, however, we have a very limited set of vendors to turn towards. Although there are plenty of browsers in the sea, ultimately there is only a precious few that gobble up the majority of users. And although users get to pick what websites they visit, we don’t get to pick what browsers to work with. (Well, we can, and some do, but ultimately we have to go where the users are or we starve). And when it comes to our needs and wants, the browser makers know we have to deal with them. We’re making sites to work on their programs, and with that necessity means we start the lose the ability to be picky. They’ll make what they want, and we have to deal.

The Priority

The balm that is supposed to take the sting out of this awkward situation is the priority of constituencies that we allegedly follow when web standards are created. Users come first, as it’s their consumption of the web in the first place that provides any of us with a job. Informed by their desires and needs, we authors (developers) are then next in the food chain. We take their needs and wants and use that as the impetus to create apps and sites. If we ignore their needs, our work fails, creating a simple reinforcement of our service to them. Ostensibly, the next step is that the implementers (browser makers) then in turn serve us. We inform them of the features and techniques we need them to build their browsers for in order to make our jobs easier and then to get the users to visit our sites (on their browsers).

As good as this situation sounds on paper, in reality it’s something different in practice. The WHATWG never stops in reminding us that if the browser implementers don’t want to add a specific feature, there’s no way to compel them. Therefore, whenever a conflict of interest appears between a developer-crafted solution or a browser maker-crafted solution to a given use case, the browser maker’s option is chosen first by the WHATWG. Frequently it happens with far less scrutiny or careful examination.

It’s this exact sort of situation that has resulted in this week’s general outbreak of developer rage (mine included).

Ends and Means

I might be willing to consider an implementer first ideology (unlikely, admittedly, but it’s possible) if everyone involved was behaving in a fashion that appeared ethical and respectable. But this recent situation is one of many that shows that lack of respect at the minimum, and frequently a lack of ethical behavior as well (I’ll attempt to explain why I’m making this sort of claim further on).

Unlike big corporations, who exist to make a profit and historically do so at the expense of the common man, and justify their actions by the end result of “make more monies”, I don’t believe that the ends can, or should, justify the means by which those ends are achieved.

Everyone involved: Hixie, the WHATWG, browser makers, developers; all of us want a usable HTML standard that lets us make better websites/apps. That’s the end. I’m willing to say that’s a noble end that everyone wants. But where things break down are the means. And that’s where my charity in tolerating their methodology fails, causes me to start ranting and agitating the community for extreme responses.

The New HTML Standard

So we’re in this quagmire now. The people who respect developer input and with a process that is more inclusive reside at the W3C, which maintains the HTML5 Standard that functions as a static snapshot of our unversioned HTML at a given point in time. The person who makes decisions by arbitrary dictatorial fiat with inconsistently applied requirements that favor browser makers over developers is Ian Hickson over at WHATWG, responsible for the HTML Living Standard which the majority of the major browser vendors are using as the basis for their implementations of HTML.

That puts us developers in a very awkward position of petitioning the dictator with the strong likelihood of being ignored and actively mistreated, or collaborating with the inclusive organization that nonetheless doesn’t see nearly as much traction with the browser makers (although I do believe they have an impact I think that it’s a slower one).

What’s a developer to do? Why work at all on the <picture> elements of tomorrow if they’re only going to be ignored for a srcset that sees far less scrutiny before its adoption?

I’ve proposed “occupying” HTML. I’m not naive enough to believe that a purely democratic solution is the best one, and that the optimal solution is the one with the most voices. We need intelligent, scrutinizing people like Hixie to actively doubt the soundness of our proposals. We need input from the browser makers on the feasibility of implementing our solutions on their end, and to hear their views from the experience they have gained by actually building browsers.

In short, sometimes we need the WHATWG. Besides, it won’t go away just because we wish it to do so.

So I’m going to cool my rhetoric just a bit and make a proposal of a new HTML standard that all of us, browser makers and developers, standard organizations and bloggers, can all agree on and benefit from.

Don’t worry, this standard doesn’t require too complex of a specification document. In fact, I’m going to lay it out here and now.

The New HTML Standard:

1. (H)onesty

I might also term this one as “Integrity”. My major objection with the current srcset situation is that the “communication process”, as some have deemed it, has shown another instance of what I believe is a pattern of dishonest behavior on the part of the WHATWG, through omission at the least if not through direct fabrication.

Part of Tim’s WTFWG post focused around a situation where the developer group responsible for developing the <picture> proposal were (they thought) instructed to create a Community Group to develop the proposal as part of the WHATWG process. As Jeremy Keith later outlined in his Secret Src post (linked at the start of this article), that was in fact not the case. The person proposing the Community Group was not representing the WHATWG, and a CG isn’t part of any WHATWG process.

Ian and friends get a pass, then, on actively misdirecting the developers into this particular fruitless cul-de-sac of labor. But what I wonder at, and believe is a big part of this “communication issue” of theirs, is that Ian and the others in the WHATWG saw this community group be built and go about its business, yet never spoke a word to correct their misinformation.

In short, they knowingly allowed them to occupy themselves on a pointless endeavor without raising their voice to correct false information.

To me, I see only a modest amount of distinction between permitting this charade to go on and actively lying to the group themselves. If one man knows a vial is poison, and chooses to say nothing but smile and watch as a bystander is told by the person next to him that the poison is delicious punch, and then drinks that poison, are they not culpable?

Trust between developers and browser makers is at an all time low. We’re wasting energy and time fighting each other because we no longer can trust the motivations or process of the WHATWG and the browser makers due to actions (or inaction) exactly like this.

We need to be more honest. We need to act with integrity. This constant smoke and mirrors approach to distracting developers while the browser makers go behind their backs isn’t an acceptable way for adults to behave. If we believe we’re being approached honestly, and dealt with honestly, then we’re far more likely to be sympathetic to browser makers and their own counter-proposals.

2. (T)eamwork

I don’t believe a democracy will build HTML.

At the same time, ignoring the merit of collaboration for the sake of a standard built by dictatorial fiat is is a foolish, shortsighted measure that can only be summarized as egotistical. No matter how intelligent and hard-working Ian Hickson is (and I do believe he is both), he can’t see a given problem from all angles by himself, nor replicate the output of a dozen or a hundred developers working in concert towards a goal.

Whether or not Standards are a place that egos reside, they certainly shouldn’t be.

Perhaps HTML needs a sole gatekeeper. I don’t believe it does, but I’ll admit that the possibility exists. That doesn’t mean that HTML development doesn’t need cooperation among several (preferably many) individuals each bringing their own intellect, experience and creativity to solve problems.

Bear in mind that “experience” part. Ultimately some of HTML5′s greatest battles have been over issues like accessibility, a topic that Ian has little to no formal experience or body of knowledge about. Yet despite this he is infamous in the accessibility community for his pattern of making choices that directly impact the accessibility features of the language based on his own judgement and seemingly arbitrary solutions at the expense of decades of experience in the subject by dedicated, educated professionals who deal with accessibility challenges every day.

How does that make sense? How does that make for a better HTML standard?

Outside of accessibility, look at the recent adaptive image issue. There are merits and flaws to both <picture> and srcset. Yet when it comes to usability, the former is far more capable of being learned, adopted, and easily used in the day to day workflow of developers than the latter. Even Jeremy Keith, who is far more knowledgeable about HTML today than I will ever be, has a hard time understanding exactly how srcset works, and has very real, very legitimate concerns about how it will fit the methodologies developers currently have with dealing with responsive designs (such as how it doesn’t appear to play well with em- or percentage-based layouts).

This doesn’t mean that srcset couldn’t win out in the end as the better option with some further modification. And despite overall developer rage, there are people like Keith who are motivated to help improve proposals like srcset even if it wasn’t their first pick. But they didn’t get that chance to robustly shake out the bugs before it was adopted into the spec with none of the hoop-jumping that <picture> and other community proposals have been subjected towards.

There’s are many developers that want to help HTML become the best it can be. Let them actually, genuinely help. Don’t callously disregard their efforts while blindly accepting browser maker proposals that have seen less vetting and testing.

Take advantage of the team!

3. (M)odesty

It’s very evident that Ian Hickson is not a humble man. He has consistently engaged in a pattern of adding features to HTML that he has self-designed instead of using ones developed by communities of experienced professionals who know far more about the given use cases, challenges and situations involving the problems his solutions are allegedly addressing.

See anything involving HTML and accessibility as proof of this. Or consider the debacle that was centered around <time>.

Asking Ian Hickson to be humble is probably akin to asking a lion to become a vegetarian. But when it comes to something as vital to the central communication medium of the 21st century, it rapidly becomes clear that there’s no room for one single man’s opinion to be the dominating factor.

I understand that we owe WHATWG in general and Ian Hickson in particular a lot of thanks for the existence of HTML5 at all. When the W3C permanently stalled on moving the standard forward, it was the WHATWG’s methods that helped get the ball rolling again. But as vital as that start was, the methods that fueled it aren’t appropriate, nor desirable, for maintaining the standard now that it’s in motion.

There’s a lot riding on HTML standards being decided today, as they will be in use for quite some time to come. When we consider the large scale impacts that flawed accessibility implementations can cause, we need to stop valuing our own egos over the wisdom of experienced teams that can help ensure that the standard that ends up being crafted actually meets the need of the users.

Who are, again, of higher priority than us anyhow.

This should apply to the browser makers themselves as well.

Google and Apple and Opera make browsers. They work on making browsers every day. I’m not questioning that, nor am I suggesting that I know their job better than they do. I can say in all modesty that I cannot replicate their efforts.

But when it comes to making websites, they cannot hold a candle to the flame that is the experience of us developer dogs that are in the trenches every damn day. Websites are our bread and butter. Websites are the source of our paycheck.

I put meat on the table with websites. Do you understand me, son?

So no matter how much experience they have in making browsers, when a large and experienced team of professional developers designs a solution to a problem that represents a common use case that we have to deal with, the browser makers need to get a little more modest and actually listen to us.

I’m just saying that I’m sure browser makers really thought <blink> and <marquee> were good ideas at the time.

We know our job, guys. Just lend us your ears and let down your walls of ego. Even if you decide not to adopt proposals we make (for browser-related reasons that we don’t understand) you just might learn enough of our problems to modify your own solutions to better fit our needs.

4. (L)iability

By which I mean accountability.

I’m accountable to the users (and of course, my clients). Every day they (hopefully) use the websites I make. It doesn’t matter how I code a site, or what my personal preferences on feature selections are. If they can’t use the site, if they can’t use the site, then I’m doing a disservice to my clients and frustrating the users.

I don’t like flash video players. I prefer <video>. But I also know that at present sometimes I need to make use of the former for certain use cases, and use the best tool for the job to meet the user’s needs.

By the same token, the browser makers are accountable to us. I don’t care how hot, fast, and feature-rich your browser is. If I don’t have a good way to take those features and add the implementation of them to my work flow, they’re not going to end up in the final product and the users will never see them in my websites.

Srcset may be a good tool. But it’s not presently one that seems very easy for me to grok, or use. I’m furthermore worried about how to adopt it into a percentage-based responsive design. <picture>, by contrast, is easier to use, easier to understand, and for the most part it does what I want it to do (and more importantly behaves the way I expect it to behave). It uses syntax that is familiar to me and lowers the barrier for me to adopt it into my workflow.

The priority of constituencies isn’t supposed to be lip service. It’s a formalized way to express something that is common sense. I need to build sites that fit the needs of users. Browser makers need to build tools that I can actually use.

It’s true that without browser maker buy-in, a feature can be in a standard surrounded by glowing letters and angels and it will still never actually end up in a browser. I get that. But there’s also no point in building solutions that don’t see wide adoption because they’re an awkward fit, don’t fit our use cases, or don’t fit our workflow.

You are ultimately accountable to us, reliant upon our willingness to champion your features and encourage their adoption by our peers in the community.

Am I Being Unreasonable?

I don’t think I am. I’m asking people to be more honest, work together, check their egos at the door and remember that ultimately our livelihoods all come from the bottom up. We developers rely on the users, and in turn the browser makers rely on us.

That’s an HTML Standard that I think we can all agree to. That’s the sort of reactionary activism I’m asking from everyone in the community: developers and browser makers.

Work with us. Communicate with us. Learn from us. Respect us. I guarantee that in return we will treat you in kind.

In his post that I linked at the top of this article, Jeffrey Zeldman said something that I believe is both very humble for admitting his own potential faults, and suggests an experiment for Hixie to consider.

In theory, if we are frustrated with Mr Hickson’s arbitrary dictates or feel that they are wrong, we can take our ideas and our grievances to the W3C, who work on HTML5 in parallel with the WHATWG. We should probably try that, although I tend to think things will continue to work as they do now. The only other way things could change is if Hixie wakes up one morning and decides benevolent dictator is no longer a role he wishes to play. If I were in charge of the future of the web’s markup language, with not just final cut but every cut, I’m not sure I’d have the courage to rethink my role or give some of my power away. But perhaps I underestimate myself. And perhaps Hixie will consider the experiment.

Ian, I’ve said very little about you that is kind. I know that. But if you took Zeldman up on his experiment, and took me up on being part of this HTML Standard I propose, you would prove me utterly wrong about every unkind word I’ve ever spoken.

That’s some crow I would gladly eat.

The Egotistical Puppet King & I

Tuesday, May 15th, 2012
CSSquirrel #93: The Egotistical Puppet King and I

In a way I should be grateful to Ian “Hixie” Hickson for being an egotistical tyrant. Without his inability to acknowledge that a consensus-driven, well-crafted and usable solution built by a group of well-meaning, hard-working people could actually somehow be better than his own personal opinion, he’s pulled me out of my long-hiatus and back to to the drawing board.

Today’s comic is in fact three comics. No single idea could encompass everything. In all three Hixie gets top billing as the editor-for-life of HTML’s “living spec”. The first comic features Naepalm, chinchilla alter ego of fellow Mindflier Janae Wiedmaier. The second one includes the irreplaceable Justin McDowell. Lastly we see Matt May, Dylan Wilbanks and Ethan Marcotte joining forces with the Squirrel in a bid to take down the HTML king.

(Today’s comics as per usual aren’t meant to imply that the people represented therein endorse my views. I’m saying it outright today because I’m feeling particularly vitriolic and don’t want my words to reflect on them.)

The Situation

For those of you just tuning in, today’s outrage focuses around Hixie’s decision to adopt a problematic, late-arriving, Apple-proposed attribute of the <img> tag into the HTML standard as the solution to the adaptive images issue. In the process he again reinforces his inability to heed the creed of HTML’s priority of constituencies (end users over authors over implementers) while also tossing away the hard work of a community group of developers that built a very functional, very usable solution to that problem in the form of the <picture> element.

If you’d like a summary, you can check out the aptly titled WTFWG by Tim Kadlec, or take a look at Zeldman’s take on the situation over here, which links into an A List Apart article by Mat Marquis on the topic.

I wish this was a new situation. Or that it was surprising. Or that I didn’t feel like I was repeating myself each time I mention Hixie in blog or comic form. The fact is that as the Editor of HTML, Ian keeps doing this. And we keep letting him.

The Puppet

At one point I attributed this issue solely to his gigantic ego and clearly overwhelming case of not invented here syndrome. Now I’m frankly convinced that although these qualities contribute to the problem, the real issue is that he’s the puppet of the browser vendors, namely the three most involved in WHATWG: Apple, Opera, and Google. Although the priority of constituencies dictates that implementers (aka, browser vendors) should be lower priority than developers (who are in turn answerable to end users), it seems that without fail Hixie will bow to the vendors before considering any work on the part of developers at a solution, no matter how reasonable, well-built and documented that solution is.

That’s not a kind accusation, that a man is a puppet. But clearly every attempt to work with the WHATWG has always resulted in developers being treated as second-class citizens to the browser makers. And let’s make it clear: this is our job. We make websites for a living, and the tom-foolery that Ian is engaged in is directly impacting our present and future workflow. We work on making websites every damn day. We know what works for us, and what doesn’t.

And he doesn’t care in the slightest.

“Work With Us”

At this point, Hixie and his backers are relying on the same smoke and mirrors to distract people. Present use cases. Keep engaged with the WHATWG and let them know your technical objections. Get involved in their IRC. But the fact is we as developers have done this over and over and over. Yet at the end of the day, regardless of the hard work put in and all the proof jammed into the pudding, it all amounts to naught. Hixie spends twelve seconds coming up with his own solution or takes what the browser makers gives him and uses that instead.

It happened with metadata. It happened with the <time> element. It’s happening now with responsive images.

The fact is that Ian doesn’t give a shit.

He’s going to do it his way, or failing that he will do what Google and the other browser makers in the WHATWG tell him to do. He’s not going to look at what the developers have built and give that solution a thumbs-up. As John Foliot said: “Dev community, if you continue to author to the WHAT WG doc, you lend your tacit support to heir hixie. Look where that gets you.”

Enough Is Enough

Being part of their process is being part of the problem. I’ve never seen things resolved by following the WHATWG’s “process”, as it amounts to little more than distracting developers while he goes off and implements a less functional, more complex solution to the problem.

Don’t deal with Hixie. Don’t deal with the WHATWG. Directly object to the browser vendors. “Occupy” HTML by making use of the consensus-built techniques that already have functional polyfills. Do what makes sense, and what works for you.Sooner or later, the browser vendors will be tired of the grief sent their way and tell Hixie to roll over.

<time> wasn’t fixed because we followed the WHATWG’s process.

I’m going to say it: I don’t believe that WHATWG is part of the solution anymore. As I’ve been told by others, democracy isn’t always the best approach. Sure, ok. But so far when it comes to the community-build, consensus-driven approach and Hixie’s brain, the community’s solution has proven more effective more often.

I’m going with the community, not the puppet.

Can Hixie’s <Data>leks Exterminate <Time>?

Thursday, November 3rd, 2011
CSSquirrel #88: Can Hixie's <Data>leks Exterminate Time?

Edit: Roughly twenty minutes after I posted this, the W3C took action on the issue, insisting that the <time> element be placed back into the specification. You can read about it here. But please read on. It’s a good primer for the next time something like this happens.

Contrary to what you may have already heard, the <time> element hasn’t disappeared from HTML.

Yes, officially <time> is currently not part of the HTML spec. (Thanks to the muddle that is “HTML Living Specification” I’ll be honest and admit I’m not sure if is no longer part of HTML5 or it’s in some sort of Schrodinger’s Cat quantum-zombie state of existing in HTML5 but missing in the “ongoing HTML” that the WHATWG is proud to keep rolling down the conveyor belt.)

That doesn’t mean it’s not being used by authors (how’s Drupal builds, 2.6 million WordPress installs and the Boston Globe for you?) nor does it mean that is it not being used by user agents (ever-plucky Opera supports it).

What it means is that a single human being has decided that he doesn’t care for time one wit, and that a rather vague element called <data> can replace it instead.

This human is none other than Ian “The Benign Leviathan Dictator For Life” Hixie, editor for the HTML specification.

I could give you an explanation on how this scenario came to exist, but two Brits who are far more informed than I am (and likely slightly smarter) have made their own summaries. If you like knowing what’s going on (and I do) then go read them. These pair of fine gentlemen, Jeremy Keith and Bruce Lawson, both guest star in today’s comic as the good Doctor thanks to a little spot of regeneration, where they’re fighting the good fight against Hixie’s <data>leks.

Virtually every problem I have with a single person wielding so much power over such a fundamentally important pillar of the web as HTML can be summed up in this incident. <Time> is officially out, despite the lack of merit or consensus in that decision. And it took just one man to make that happen. Either through a lack of awareness or a genuine disregard for what authors are already doing, Ian has claimed incorrectly that <time> isn’t seeing adoption, isn’t useful, and should be canned. And because the only balance to his power is a rather tedious process to oust him, there’s no official remedy to bringing <time> back into the HTML fold than trying to convince him that its existence is a good thing.

From what I understand, it’s easier to keep red shirts alive on away missions than it is to change Ian’s opinion on something.

Fortunately, there’s a big difference between having no official remedy and having no remedy whatsoever.

As “authors”, we are the 99% of HTML5. We can follow Jeremy Keith’s sage advice:

We can make a stand and simply carry on using the time element in our web pages. If we do, then we’ll see more parsers and browsers implementing support for the time element. The fact that our documentation has been ripped away makes this trickier but it’s such a demonstrably useful addition to HTML that we cannot afford to throw it away based on the faulty logic of one person.

So as I said, <time> hasn’t disappeared from HTML. It’s still there on millions of sites already. And nothing is stopping us from putting it on millions more. It’s our chance to send those <data>leks packing. As soon as this post is finished I’m going to edit my site’s theme to make use of <time>. Hixie can go stuff it.

Occupy HTML5.

Comic Update: HTML5′s Unicorn Heuristics

Tuesday, June 15th, 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?