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.