Disclaimer: Once upon a time I worked for a web development company that no longer exists. Several years of my life and career involved that company. This comic, and some more to come, will involve parts of my life during that time, and as a result involves the actions of others that worked there. I want to state clearly: these are not meant to be posts about them. They aren’t attacks. They’re posts about me, and defining moments that impacted my life, which just happen to involve them. Humans are complex shades of grey, a mixture of good and bad decisions. I’m not trying to paint anyone as a villain. Please bear that in mind.

The reasons that CSSquirrel ground to a halt over the years are legion. Like everything in life, it came from a recipe with many ingredients. But the comic above describes the nexus of those reasons. The intentional exploitation and the lack of a *single* word of thanks, never mind remuneration, hurt. It hurt so much that I have tried and failed to write about it over a dozen times in the past two years, each time deleting it for fear of “causing drama”, while simultaneously trying to dig the burning embers out of my gut. It became a logjam, standing in the way between the part of my mind that was motivated to make comics and write blog posts, and the rest of the world.

Labor Day weekend, 2013, was the single worst experience I’d ever had as an employee. It was worse than working in a call center. It was worse than having a hamburger thrown at me by an angry customer when working in fast food. It was worse than arriving for my shift at the grocery store that was my first job only to learn that more than half of the store’s employees, including myself, were laid off without notice.

In old tweets at the time I referred to the incident as my own personal road to Damascus, and to Angular (which I first learned in that fateful project) as my personal Ananias. I wasn’t converted to the faith of a framework, mind you. This is a conversation for another time, but I’ve always had an uncomfortable tension with Angular, which seems to me to enjoy complexity for its own sake. Instead my eyes were opened onto financial conflicts of interest between myself and my employers involving my career trajectory. I was pushed into a 90 hour week for the sake of making a client project easier to sell while making a profit. Worst yet, they were hoping to have me do that for them more often.

It was the first time that I thought “Maybe these people don’t have my best interests at heart”.

That loss of faith, that loss of innocence, was never recovered. It was also the key moment where my hair literally went overnight from a largely brown mass with a few silver rogues to something strongly entering the “salt and pepper” category. And with that was lost a large portion of the joy that I experienced as a developer. The joy that comes from staring at a screen for hours as I wrote code that made cool interactions and fascinating experiences that non-coders equated to magic.

I’ve been programming since I was twelve. That’s over two decades of coding, as either a hobby, or a job, or both. Other people play Frisbee golf or carve bears out of trees with chainsaws to relieve the stress of life. I would make a video game or build a website.

And then that sense of fun was gone. It was just a job. And I had to fight for respect in that job. For my self-worth. Every moment of coding became solely an exercise in self-improvement and proving my right to be in this career.

There was no place for a comic about a squirrel, or humorous quips about browser standards, when I was in that place. I still deeply cared about web development. I cared about my career. But I didn’t have the luxury of having fun with it anymore. I’d go through the motions. Quips on Twitter. I would open Photoshop and move around shapes. I would make a note of a development in the field and say “I really need to make a comic about that.” And nothing came of it.

Time doesn’t heal all wounds. It’s a stupid saying. But it does heal some. The joy of coding, the sense of fun has rejuvenated as I’ve joined new teams, had new experiences, and even been lucky enough to travel internationally for conferences related to web development. There is a renewed sense of whimsy. And I can’t think of a better balm for this oft-harsh world than whimsy.

The truth is, I miss the squirrel. The little fuzzy guy is an avatar of excited energy that represented the frenetic, irrational excitement I have about being part of this community of developers and designers. The crazy things we can do, and the esoteric disagreements we can have trying to do them, and the amazing, life-changing people I’ve met here.

And, for reasons that never fail to amaze me, there’s others out there that seem to be missing the squirrel as well.

So, clearly when put to a vote, the answer is “A world with the squirrel is better than one without one.” Who am I to argue with that?

Starting tonight I’ll be creating a weekly podcast about making websites with one of the most thought-provoking web designers I know, Dylan Wilbanks. Broadcasting humor and thoughtful commentary on the current issues of web design, development, and technology from the rain-soaked Pacific Northwest, we’ll be putting up a new episode every Thursday night.

We’re being provided hosting by 3rdaverad.io, which will be making the podcasts available (for the price of free) via RSS and iTunes, alongside their other great programs, including Jeff Croft’s and Mat May’s Weekly Chat.

Tonight we’ll be kicking the tires and checking the oil with our pilot episode, and will be getting the resulting product hosted as soon as possible for the pleasure of your ears and brains. I hope you’ll take the time to check us out!

I’m really pleased to announce that I’ll be one of twenty speakers at the CSS Dev Conference on December 5th at Honolulu!

Which leads to reason. After all, you can’t spell CSS without CSSquirrel. (My writing team helped me come up with that one.)

Not only that, I’m apparently an “Industry Leader”. I’ve included a screenshot of the speakers page below that clearly states just that. So now we all have proof forever and take that high school jerks who’s laughing now?

Ahem. I mean, yay me.

I’m the one on the lower left corner with the super cute dimples.

I am so printing this out and putting a copy on the fridge right next to my report card.

I’ll be both speaking and performing functions as Cartoonist in Residence.

I would love to see you there. Yes, you specifically. No, don’t be bashful, we both know you’re super cool.

I’ve got a discount code for $50 for anyone who goes and registers at cssdevconf.com. It’s KYLE. So make sure to tell them I sent you.

Ok guys I’m going to go scream into a pillow for a few minutes then call up my best friends and jump on my bed in exciteme- er, I mean act in a cool, professional manner as I gratefully thank CSS Dev Conference and its organizers for this wonderful opportunity.

See you there?

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.

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.