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.

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.

Featuring Remy Sharp, Tantek Celik and Bruce Lawson, today’s comic would make the perfect premise for a sitcom. I think “Three Developers and a Squirrel” would have a very nice ring to it. The comic also looks at the stinky mess we’re going to put ourselves into if we fail to recognize the problems of the past so that we can avoid repeating them.

In a move that threatens to undo over a decade of hard work to drag web development out of the horrors of the “Great Browser War” and educate developers to make forward-compatible, standards-compliant websites, the CSS Working Group recently discussed the idea of all browsers adopting -webkit CSS properties. Yep, you heard that right. IE, Opera, Firefox… all using -webkit properties.

This step appears to be intended to guarantee that their browsers will properly render websites being made by short-sighted developers who only bother using -webkit properties for advanced and experimental features in their websites even when the other browsers have their own test implementations such as -o, -moz and -ie.

Short version: They’re considering giving up and handing the browsers of the world over to a bunch of standards-blind morons for short term compatibility gains in exchange for long term problems that will make the current version of Webkit be the IE6 of tomorrow.

I’m not a member of the old guard. In the nineties I was in high school and pretending to be in college while making personal websites that were just short of visually hideous but definitely counted as nauseating. I didn’t know better. But thanks to the efforts of too many dedicated and educating web developers to name I was exposed to the concept of “web standards” and went about the process of learning how to do things properly.

I also landed a sweet job at Mindfly and became a member of the professional web world. All thanks to web standards.

As someone who’s been working on websites professionally for the past five years I’ve had my share of struggles with IE6 compatibility. I hate that browser more than I hate most other things on the planet. Intellectually I know it was the bee’s knees in its era. I don’t care. Its era was a long time ago and being forced to keep sites compatible with it due to the lack of standards in its era is a direct cause of hundreds of hours of suffering on my part. I’m grateful that it is now all but extinct, letting me concentrate on dealing with modern or near-modern browsers with a lot less cussing, sweating and crying.

As it stands now, Webkit is a pretty decent browser engine. Chrome is snappy. I like it. I’m using it right this second. But it’s also only as good as it is today. If we stop bothering to properly style our websites with a forwards-compatible approach, using all available browser extensions for experimental properties as well as the non-extension version of the properties for when they becomes available, then we’re daft. We will be putting ourselves at risk of making today’s Webkit the rotting zombie in the room that we’ll be screaming at in terror ten years from now. We, or developers after us, will be wasting countless hours and drinking more heavily in response to dealing with thousands of poorly-made websites that require compatibility with the -webkit properties we shortsightedly hung everything upon.

We need to stop this.

Need more information? Need inspiration on how to help? Lucky for you I’ve got a list:

• Read Daniel Glazman’s Call For Action. He’s co-chair of the CSS Working Group, and he knows that this is a very bad thing that needs to be stopped. He even suggests how to do it.
• Also read Remy Sharp’s article on the topic and his suggestions on how to help.
• Take direct action and help Chris Heilmann Pre-fix the Web, rooting out Github projects that have gone down the dark side and get them forked back into the light.
• Get Bruce Lawson’s perspective on the vendor prefix issue, taking advantage of the wisdom he’s gained in trying to educate against this exact sort of problem. Also see the first reference of the dreaded vindaloo fart.
• And please read Eric Meyer’s pessimistic, but perhaps realistic, assessment of the issue in Unfixed.

Whatever you do, don’t be apathetic. Don’t think to yourself that -webkit only sites are professional or even remotely acceptable. Because they’re not. It takes very little effort to guarantee forward-looking, cross-browser websites with the vast majority of most modern CSS properties. Doing anything less for the sake of ease is lazy, unprofessional, and going to cost someone a lot of money and effort in the future.

If you do decide to only use -webkit prefixes, watch out, because Bruce Lawson will vindaloo fart on you.

Compare that to a container that has a width of 1000px. 1000 is a nice, easy, round number. Dividing by 1000 results in clean percentages and better still, dividing by 1000 is something we can do in our heads: just remove the zero. A 140px column inside a 1000px container is 14%. A 500px column in a 1000px container is 50%. 320px is 32%. Easy!

Check it out.

However, I am following along via Twitter, and saw this announcement by Jeffrey Zeldman, web design godfather and co-founder of An Event Apart:

.@simplebits just unveiled Pears pea.rs, an open source web design pattern library/WP theme. #aea

Pea.rs looks like a convenient little tool for web designers to bookmark, a library of sorts where commonly needed HTML/CSS patterns for common page elements like navigation, lists and such can be quickly grabbed and used. I’m sure you’re all so amazing that you don’t need it for your markup, but I also think for prototyping some page elements this might be a good resource to go-to to quickly grab and paste. You might also find a few new ideas on how to arrange your markup or CSS, too.

Check it out.

Soap isn’t our enemy. Properly done, copyright and the enforcement of it isn’t our enemy.

But SOPA and PIPA, the legislation currently being considered by Congress, pose a very real and dangerous threat to a free Internet as well as free speech.

Today, January 18th, a lot of sites are blacking themselves out in protest over SOPA and PIPA, helping show how the Internet might exist if these legislation are allowed to pass.

Get informed. You can see some people’s carefully considered views on how dangerous SOPA and PIPA are here, here and here.

Get involved. Tell your senator or representative that SOPA and PIPA are bad.

You know, no biggie.

Well, thanks to the help of Stefan Pause I’ve managed to kick that little infection in the posterior. Thanks, Stefan, you were a big help!

Now back to our regularly scheduled program.

Today’s comic features Opera’s viking doing some nasty, brutal stuff. Because if a public community representative of Opera acts out of line, and the company doesn’t call them on it, they might as well be endorsing it. Luke Wroblewski also stars as the stand-in for well-meaning folk who are trying make peace at the expense of correcting bad behavior.

Buckle up.

I’m going to throw myself on the grenade and be the curmudgeon.

You don’t have to like what I’m about to say, but I think you need to read it.

We are, as a community, allowing ourselves to be abused. We’re Kevin Bacon in Animal House, bent over in our underwear and thanking someone for beating us. And, like any sadist with a free pass, they’re continuing to hit us again, and again, and again.

I get it. It’s the holidays. We’re stressed out by end-of-year deadlines, driving on icy roads and getting our Christmas shopping completed and hoping that at the end of the day we can kick back an egg-nog and just be merry. We don’t want the stress of confronting and condemning bad behavior, so we’re trying our damnedest to shrug it off.

Additionally, most of us want to be liked. And we want our friends to like each other. Whether it’s in our neighborhoods, in our Facebook profiles, or in our professional circles we just want people to be friendly and think highly of one another, but especially us. So when a flare-up starts between two peers we’d rather put our fingers in our ears and hum the Benny Hill theme song than owe up to the fact that there’s a problem.

But I’m here to be the bearer of bad news: there is a problem. Not only that, we’re responsible for it.

When I was growing up, my mother made it clear that certain behavior was not acceptable. Among other rules of childhood, I couldn’t go about tossing insults at people. Not my parents. Not my siblings and not friends. Heck, I was expected to maintain at least some decorum around the kids I disliked.

Going outside the bounds of socially acceptable behavior carried with it a penalty. Maybe soap in the mouth, or a spanking, or being grounded in my room, or at the bare minimum no desert after dinner. It was unpleasant. I was a pretty big crybaby, so any sort of punishment or chastising resulted in a waterfall of tears and a sniffling cry that would last for hours. I guarantee my mother hated having to deal with it. She probably would have enjoyed her evenings much more pretending I didn’t doing anything wrong, instead of listening to me cry and sniffle in my room as she desperately tried to read a book in peace.

But she did it anyway. As a result, I learned the difference between right and wrong and stopped doing the bad behavior. It didn’t mean that I stopped thinking ill of kids I disliked, or devising a choice insult for my brother when he provoked my ire. But it did mean I knew it was unacceptable to act on those thoughts, and it made me consider my words before I said them. If, after a good hard think I decided it was worth provoking my mother’s wrath, I’d still take the risk of insulting someone.

I did, however, think first.

In a pattern that goes back probably for quite some time but for certain seems to have flared up this week we’ve been permitting ourselves to be subject to bad behavior. We’d rather read our books in peace, so we are ignoring the misdeeds of an entitled few in the hopes that it will all go away.

And it’s not going away.

There’s literally thousands of amazing, talented developers and designers currently involved in making the Web a better place. A whole lot of them are like me, working hard for a very modest living in a small design firm that doesn’t get awards or fancy big-name clients. A great many also work as embedded Web people in a large corporation or other entity, thanklessly fighting the ignorance or misinformation of their bosses and co-workers while trying to apply their awesome skills to making their corporate site a better, slicker place to visit.

Then there’s the superstars, Web folk that work as community representatives and star developers for the big Web companies that take leadership roles (by fiat or by standards) in developing and proselytizing the advancement of the very technologies we use to make awesome Web stuff.

These people don’t just speak at conferences, they speak at dozens of conferences. They don’t just make cool web projects. They make amazing, cutting-edge projects that push forward the meaning of “good Web design”. They talk a lot about community participation and self-learning and being involved.

They’re intelligent, creative and successful people.

Sometimes, they can be utter dicks.

Anyone can be a jerk. From the drug-addled homeless man currently shooting up in the alley down the street from my office to the richest men in the world. Every person is capable of forgetting those lessons in basic decency that their parents (hopefully) taught them as children and slip up from time to time.

When it happens, it’s usually considered acceptable to say “Dude. No.”

The worse the bad behavior, usually the more stringent the chastisement should be. Action. Consequence. It’s a no-brainer, right?

But what happens when thought leaders, community representatives of important companies in the industry, and superstar talents start to repeatedly engage in or endorse bad behavior? It usually goes something like this.

1. The superstar does something socially unacceptable. Like refer to a recent article by the owner of a small design firm as drug-enduced bullshit. (original was deleted, here’s a retweet).
2. Individuals call the superstar on the behavior, noting how unacceptable an action it is. Especially for a community representative of a major player in our industry (although, really, it’s just unacceptable period).
3. The superstar sort of apologizes. Usually in the vein of “I’m sorry for using strong language” or “I’m sorry you got upset”.
4. The individuals (rightfully) insist that’s not an acceptable response, and demand a genuine, public apology.
5. The superstar does so.
6. Supporters of the superstar retaliate by calling the original individuals the curmudgeons in this situation. They in essence defend the bad behavior by shaming them for “bullying” the superstar, say the “crap” they’re saying is undeserved.
7. The rest of the community, straining to retain a smile, do everything in their power to bury the “firestorm” under a (likely well meant) pile of hugs and cookies universally handed out to everyone involved, including those that defended the bad action and the superstar that did it in the first place. All are pardoned, nobody is wrong.
8. The superstar states how tired they are of the drama… seemingly ignoring the fact that it was their own behavior that caused it.

This is all sorts of messed up. Nobody’s learned a lesson, because as a community we’re too concerned about “drama” that we’ll do anything to quash it instead of uniting as a community to call down the person who started the drama with their attack in the first place. We’re sending such a mixed message of supporting the peace or the person without collectively condemning the behavior.

Anyone who ever raised a kid or was a kid knows exactly where that will lead. To more bad behavior.

I’m not calling for punishment. But the launch of a pro-community “make the web better” website (which I will not be linking or mentioning by name for reasons I’ll make clear below) should have been a source of joy in the holiday season. Instead, two individuals tied to that effort have engaged in either passive/aggressive sniping or outright insulting of individuals and their efforts in this week alone. And according to people in the know, this isn’t the first time for some of those involved. And what kills me, what hurts me is how highly I thought of these people prior to now. But how can I promote the work of people who engage in socially abusive bad behavior?

I can’t. No matter how much I agree with the message of their product, I cannot in good conscience promote their goods and services when they’re behaving in a fashion that I know to be wrong. And as near as I can tell, they’re not sorry for how they’ve behaved. They’re simply sorry they were called on it.

The only way we’re going to improve as a community is to grow up and realize we can’t hide everything under soothing hugs and cookies. People messed up. Worse yet, people who are well known and respected representing companies with power or social clout messed up. If they are protected for their behavior, they will continue to abuse us, the community. And many of us will, over time, mimic that behavior in a misguided attempt to become as successful as they are.

Shame on you, Divya. Shame on you, Paul. You’re grown adults. You know better.

Next time you want to blame the drama, stop for a moment and think about who actually started it.

And to the rest of you, I’m sorry. I don’t want a cookie. I want it made clear that this behavior should never have happened, and can’t be allowed to keep occurring.

Happy holidays.

• Firstly, there was a great comment thread on my post including voices such as Divya’s. Check it out.
• In particular, you should read John Foliot’s response at the end.
• Jeremy Keith’s Pursuing Semantic Value is a must-read. In it he agrees with Divya’s core message, notes an issue with tone, and guides you through the process of where his agreement with that core message takes him to a very different conclusion.
• Steve Faulkner replies to Jeremy’s article with a comment that grows up to being a full-sized article of its own: HTML5 Semantics and Accessibility.
• Paul Irish, a veritable Chuck Norris of web development, also wrote in response to Jeremy Keith with Semantics in practice and mapping semantic value to its consumers.
• John Foliot responds to Divya in a detailed, no-holds barred post that examines the merit (or lack thereof) of her speaking points about semantics in My Thing About the Thing That Thing Wrote About Thing.

If you have time, you should read all of these. They’re all written by intelligent people getting into the heart of the HTML5 semantics debate with more clarity and detail than I could ever manage.

Divya Manian is a bright cookie. When it comes to the web, you can say with complete assurance that she knows her s***. She’s in that category of people that makes me insanely jealous of their creativity and intelligence.

All of which makes me think that somehow she’s trolling us today.

Our Pointless Pursuit of Semantic Value is a shortsighted piece, placing the value of markup solely upon the capabilities of browsers (and other user agents) today at the expense of tomorrow. It’s the sort of article that I would have perhaps expected from the internal website developer of a large corporation at the turn of the century that only permitted its employees to use Internet Explorer 6.

When I started getting paid to make websites instead of pizza, I was bombarded non-stop by the value of making websites that weren’t locked into the limits of the less-capable browsers of the moment (some of which, like the big blue e, were more than a little antiquated), but was instead encouraged to embrace forward-looking mentality of making the best of emerging features where I could and creating a fallback position where necessary. I can’t remember if we called this graceful degradation or progressive enhancement (I’ve heard the two used and misused so much that they blur in my brain), but nowadays we just call this technique “common sense”.

Did I make special span tags on elements that had rounded corners, placing background graphics on four separate corners so that the Great Blue Mentally Misunderstood Beast of the Internet could have pretty edges? Hell, no! I used border-radius and knew that somehow, someday, all browsers would eventually understand it meant I wanted pretty, round corners to nuzzle up against and whisper sweet nothings to at night.

I’m aware that HTML isn’t CSS, and what applies to one doesn’t necessarily apply to the other. But I’m fairly convinced that if anything, the principle applies even more with HTML today than it did with CSS yesterday. Barring a few legacy browsers that need to ride the HTML5 Shiv/Shim Short Bus, using a div or a header isn’t going to have any impact on a browser’s ability to properly render an element. Which means there’s no harm being done by using a semantic element before user agents get around to taking advantage of its extra meaning.

If I had to summarize Divya’s points in her article (I recommend you read it rather than relying on what’s bound to be a dramatic oversimplification on my part), it is that we shouldn’t bother with semantics because:

1. Semantics Are Hard
2. Current Browsers, Search Engines and Assistive Technology Don’t Understand It, So Don’t Bother
3. Spending As Little as 40 Minutes To Learn About HTML5 Markup Is A Waste Of Time

Semantics Are Hard

Divya points out a piece by Mark Pilgrim on the difficulty of semantics. So, Semantics is hard. So what? Last I checked, I was a professional doing a job for a living. It’s my job to know what part of a website is its navigation or is its primary content. HTML5 isn’t really demanding much brainpower from me on deciding what element to use for what job. I’m fairly confident that the general meanings of header, footer, nav, time, audio, video, progress and summary elements are easy enough to grasp as a person who works with websites for a living. Agreed, article and section are a bit confusing, but I don’t think by and large that HTML5 semantics are a byzantine labyrinth of alien thought impressions that cannibalize the minds of sane men.

Current Browsers, Search Engines and Assistive Technology Don’t Understand It, So Don’t Bother

When I was making a few years back, Internet Explorer didn’t understand border-radius. Yet, despite that, I used it in making websites. And not only does IE now understand (and render) those pretty corners, but many of those websites still exist, using the same code I wrote back then. If I had chosen to not use border-radius because of the limitations of the time, the sites wouldn’t look good today because of my short-sightedness.

HTML5 is still settling down into its patterns. Some of the meanings are still being locked in. It’s not “done”, as evidenced by Hixie’s arbitrary and somewhat bizzare attempt to remove the time element from the spec. Does this mean that I shouldn’t be using elements from the specification because it’s not done now? Of course not! The sites I’m making today will not only be live for years, they very likely won’t see a redesign for much of that lifetime. Relying only on what’s “finished” now would be a disservice to my clients today, preventing them from benefiting from features for years because of a technicality on the spec’s status or the full support level of browsers.

AT, browsers, search engines, they will all catch up with taking meaning from semantics at some point in the future. When they do, would you rather that your website was ready for them, or would you like to spend time (and money) re-coding your mess of divs into something slightly more relevant? There is no harm in using divs now (when other, more semantic elements might be better). But there is a very good chance that it will put your site at a disadvantage later, when the technology catches up.

Saying that I shouldn’t use semantic markup because AT, browsers or search engines aren’t consistently taking advantage of it in the present is like saying that I shouldn’t use video or audio elements because some browsers aren’t taking full advantage of them yet. It’s limiting my future benefits by over-adhering to the present. How many of Divya’s CSS tricks shown at her presentations at conferences work on all current browsers? In all likelihood, none of them. Does that mean they don’t have value, and shouldn’t be used?

How is making use of semantic markup any different?

It’s not.

Spending As Little as 40 Minutes To Learn About HTML5 Markup Is A Waste Of Time

I am shocked that she said this. I’d almost characterize it as insulting. We are professionals in a career that demands continuing education.

At the end of the very same post, Divya suggests that developers learn Javascript. Which is good advice. Learn it. Love it. But how can you advocate the value of self-education while simultaneously characterizing spending forty minutes of your time to familarize yourself with the meaning of some of HTML5′s elements as a waste of time?

Sometimes the choices we make in markup don’t result in manna from heaven. Personally, I don’t attempt to adhere to sensible, semantic markup for the sake of SEO (which I consider a bunch of snake oil bulls*** anyhow) or for accessibility purposes. I do it because there’s an inherent value in attempting to do something in a consistent and correct fashion. There is meaning and purpose in constantly attempting to improve one’s level of craftsmanship.

There is nothing pointless in pursuing good standards, including adding semantic value to your website. Even if there was no future benefit to properly, professionally crafted markup (and there will be), there’s an inherent value in taking pride in your work and producing a product that is more elegant than that of your hurried, slapdash competitor.

There is meaning in striving for meaning.

Or as Karl commented in Divya’s post:

inadf, rjfsnsl nx pjd yt zsijwxyfsi jfhm tymjw. ny’x ymj xthnfq htsywfhy ns gjybjjs tzw nijfx. dtz fwj rncnsl uwthjxxnsl fsi rjfsnsl. vznyj xfi.