So here we are, yet again, faced with yet another Crisis Of Web Standards. Yet again someone has offered a Modest Proposal, and yet again the chorus of Upright And Decent Web Designers has responded that The Line Must Be Drawn Here, This Far, No Farther.
And in the middle of all that, the vendor prefixes came along because we wanted to let browser makers beta new ideas without polluting the standards stream. And there were many complaints, but one surprising ally.
So we embraced all these things — a way to work around the slow progress of standards — because wanted our sites to be cool. We wanted them to have motion, animation, gradients, and all the awesome things we used to have to use Flash to pull off. And with a captive audience in iOS, we could use responsive design to really make them think They were Living In The Future.
But now we face the cost of all this need for speed: An ecosystem that so requires -webkit other browser makers want to support them too to keep themselves from falling behind. And as the web world rages against Mozilla’s “treachery,” the W3C just went to last call on Backgrounds And Borders — five years after the great CSS3 branching in an attempt to get the standards done faster. In the time it’s taken Apple to launch the iPhone and become the single largest mobile and tablet company in the world, the W3C has moved exactly two parts of the roughly 20 part CSS Level 3 spec from draft to standard. Backgrounds and Borders, should it make it to recommendation in the next year, will make three. And during that period between Last Call and Rec, Apple will launch the iPad 3 and change the game yet again.
Now, it may seem I’m digging on the W3C, but let’s be clear: I LIKE the W3C. They are moving at a meaningful and purposeful speed. They’re hamstrung by trying to keep their component organizations from strangling one another, and they’re eternally caught between the pressure of Congress and Cloakroom* dealings, but they do move with purpose and are willing to think the issues through. Given the choice between the W3C’s mandarin republic and WHATWG’s dissent-as-thoughtcrime oligarchy, I would choose the W3C 11 times out of 10.
So what really is the problem here? I’ve concluded it’s our collective hypocrisy — those of us who’ve been willing to call ourselves Standardista (or some less pretentious title). We want standards. We want reasonable, sensible guidelines from a group that we can believe in and trust. But we also want to move the web forward. We also want to watch Dan Cederholm or Eric Meyer flip out some insane CSS3 trick that makes us run back and slam it into a current project, IE7 be damned.
And we can’t have both. Standards — meet and right standards — take time. The ongoing HTML5 debacle (which most everyone denies is a debacle, but the monthly public WHATWG-member-vs-the-world blowups suggest otherwise) is proof of what happens when you try to rush to codify half-baked ideas that are deficient in real-world use cases.
Standards ship on a software release schedule — they must be designed, created, tested, re-tested, re-created, designed, re-tested, objected to, and re-designed, re-tested, and re-objected to before they ever get the “recommendation” stamp. The web, though, isn’t software. If anything, the web is a prime example of Release Early, Release Often. Websites ship with bugs, and the bugs will get fixed by priority, tomorrow, when the designer has had some sleep. In software, though, it’s either hotfix or wait a year.
So maybe in that sense WHATWG has it right — they’re releasing early and often and assuming we will eventually settle on the rules (though whether they’ll admit they ever admit they make mistakes is another conversation). But how do we do that when we also know standards need time to bake? How do we give browser makers the ability to experiment without fear of mucking up the process?
It’s either that or extending Amaya to what it should have been all along — a canonical browser from which all other browsers should branch, built with the collected donated might of the vendors who make up the core of the W3C. Or perhaps it’s the W3C doing the same thing with WebKit. But neither of those proposals would fly. Microsoft isn’t going to let some of its best people on the IE team work directly with members of the Chrome team, and Google’s not going to do the same. They’re all in a high stakes poker game for the future of the web, and none of them want to show their cards.
Standards should be about constant iteration towards a universal. This is the web we’re talking about here, an environment that’s just reached drinking age (in the US) and that has gone from a NeXT screen to tablets and from static hypertext to animations, video, and scripted code during those 21 years. I don’t think in human history we’ve ever seen a technology grow, change, and pivot so much inside of a single generation. And yet, our standards move slowly because that’s what standards are supposed to do — move and evolve slowly.
And we should let them continue to move slowly, all while innovation continues in the sandbox of browser-specific code.
In the meantime, we look to LESS and SASS to do what Prototype and jQuery has done — be the bridge between the web we know now and the web we know should be. We pressure the W3C (and their constituent vendors) to continue the path of standardizing innovation (and perhaps join the W3C ourselves).
And we live in the hope that we don’t face with WebKit what we faced with IE in the early half of the 2000s: A de facto standard from lack of substantive competition.
It took Firefox and Safari to shake us from that near-monopoly. But what of a world where something like 90% of all the mobile devices run with a native WebKit browser?
Mobile has hastened the decline and fall of Flash. Will mobile also mean the decline and fall of web standards?