Don't Clobber The Web

"Don't Clobber The Web."

Those words have lived with me since Chris Wilson, who was on the Internet Explorer team at the time, uttered them at a Webmaster Jam Session a few years back. As much as the team wanted to tweak or improve on the standards they had set in the past (notice I didn't say "mistakes"), they couldn't.

Why? Developers.

Microsoft owned so much market share at the time that they didn't want developers to upgrade to a more standards-compliant version of IE and have anything break. They were so apprehensive because the developers would blame the IE team for all of the changes to the legacy specifications and not take it upon themselves to make the necessary corrections to bring the site into compliance.

I thought, how could developers be so lazy?

But it made sense, "breaking" IE for developers would ultimately mean "clobbering the web" for users. Developers at the time would never consider their coding practices wrong. IE would obviously be wrong.

There's that cliché, "“those who fail to learn from history are doomed to repeat it," but it's intriguing to see which parts of history are to be replayed.

Before I went to bed this morning I caught sight that vendor prefixes would be the issue de jour when I woke up, as the CSS Working Group proposed to add -webkit as a prefix to the official spec.

This might've not been the best tweet to use as another example, but it illustrates two points. One, how easy it is for people to choose sides. Two, how EASY it is for people to choose sides. Blame the developers or blame the vendors. Truth is, we all have our part in this. A response like this is exactly the same type of response Chris would've gotten in the past for wanting to move IE in a standards-compliant direction. It doesn't help. But I digress.

I've never completely bought the idea of vendor prefixes. Yes, I know they hold intrinsic value when it comes to developing features that only matter to a certain browser—Mobile WebKit is a quick example, but they've become a crutch and they've lost their intended value. I had always seen them as placeholders to soften the blow for developers as browser vendors "quickly" iterated on their implementations of the spec. But now there are tens of properties that don't need prefixes anymore as the implementations are now the same. Take box-shadow as an example.

So as to not "clobber the web," the Working Group wants to make the our lives easier by allowing browser vendors (e.g. non-WebKit browsers) to implement -webkit prefixes in their browsers. So as to not anger developers, they figure the only choice is to add a prefix to the spec. This is insanity, we should be deprecating and dropping prefixes as implementations become solid and browsers that require them lose market share, not add them to the damn instruction booklet. We should be ready for and desire the advancements that come down the pipe, but not this.

Since the introduction of Compass, I've cared about vendor prefixes progressively less, having Compass take care of all the proper prefixing for me. So granted, it's been a long time since I've talked CSS and I'm quite sure there are parts that have evolved that I lack the proper education in, but nothing about this feels right. Is the Working Group trying to help us? I'm sure, but I believe they're going about it in the wrong way. I lack a proper retort or alternate plan of action, so I've forgone cutting any heads off.

So while I will continue to use Compass and its kin to ease my personal woes, as a spectator, -webkit shouldn't exist in the spec proper. Heed Chris' words and his story, because we shouldn't live in an era where stories like that have to occur anymore. As web developers and designers, it's our job and obligation to adapt or be left behind. This is no different, and I hope the Working Group eventually makes the right decision.