Rob Wilkerson

In light of Microsoft's plans (or is it just a proposal?) for browser version targeting, I'd like to weigh-in on a more philosophical level. There are a lot of very smart people chiming in on this who are much closer to the situation than I am at a practical level. They are better equipped to speak to any implementation concerns. My concern rests at a higher (as in more abstract, not better) level.

The IE team's fundamental principle, they've said, is "Don't break the web". Noble. I actually mean that. I'm glad that they recognize the influence (both positive and negative) that they've have on the web and on the sites and applications that have been created for it. That's important, I think. I do have a problem with the principle, though, and it's kind of a big one. I can't help but wonder if that's really the best we can do. "Don't break the web?" I'm all for not breaking the web, but there should be more to it. For any company, "Don't break the web" is a frighteningly passive principle. For a company with the influence and resources of Microsoft it's simply not sufficient. How about "Progress the web" instead? Speaking normatively, of course, shouldn't the end goal of any software be to improve itself and to improve its context? Hell yes, it should.

In order to progress, backwards compatibility cannot be the guiding force. It's important, yes, but it's not the Holy Grail of software development and it simply can't be. Complete backwards compatibility introduces bloat, discourages refactoring and often prevents the adoption of evolving best practices. It probably does more undesirable things, but those jumped to mind immediately. None of those are good things. As I mentioned, I'm not arguing that backwards compatibility shouldn't be considered or shouldn't be a goal. I'm arguing that it shouldn't be the end game. Sometimes it's okay to break some things. It's just another trade-off.

I'll leave as much backwards compatibility as I can without affecting the future of my software; I'll provide automated tools, where appropriate and possible, to assist in the upgrade process; I'll share as much knowledge and provide as much consultation as I possibly can to help users perform any manual operations, but I have to keep thinking about the next version of my software, not the last 4 versions. If I'm forced to make a choice between doing what's right moving forward and preserving backwards compatibility, I'm going to choose the former almost every time (I actually can't think of a time when I wouldn't, but I don't want to paint myself any further into a corner, here).

As an example, let's talk IE7 for a minute. I'd have preferred that it go further, but with respect to this topic I'm quite satisfied with how it got released. There's a lot of backwards compatibility, but some stuff broke. That's fine. That which broke was broken in the interest of progression. I might even go so far as to argue that the breakages were a good thing. The number of broken, um, features were reasonably manageable. Sites that hadn't been maintained in 5 years maybe didn't need to remain online. Or maybe they did. The ones that did made the necessary changes and the ones that didn't were perhaps discovered, audited and taken down. The point is, a lot of stuff still worked and what didn't wasn't prohibitively difficult to fix - especially since they were being fixed for the better. Progression is worth a little effort.

With respect to the X-UA-Compatible meta tag, I need - and intend - to do more reading and thinking, but my gut reaction is this: I'm okay with the mechanism (the introduction of a new tag), but not with the implementation. I think it's exactly 180 degrees from correct. Default to standards compliance and allow for backwards compatibility.

Progression is worth a little effort.