Even clinically dead web developers will by now have seen the announcement of IE8's new versioning switch, and many bloggers I read have already reacted—most of them negatively. See the IE page of my linkblog for an overview.
All in all I am in the Yes camp, and in this entry I'd like to offer a few arguments in favour of the current default of the switch. In my opinion, defaulting to IE7 in the absence of a switch is the correct behaviour.
I won't be offering practical arguments, since these are not received too well right now. Instead, I'm hoping to appeal to our collective sense of honour.
Before continuing, a disclosure. I have been aware of the upcoming changes for the past few months and, together with Aaron Gustafson, have advised the IE team on specific issues. As Aaron has already let slip on the WebStandards.org blog, I'm working on a third ALA article that will give detailed, factual information on the working of the switch.
That article isn't yet ready, by the way. I still need some information, and the IE team, ALA, and I feel that it's more important that this article will be complete and correct than that it'll be published quickly. So you'll have to have some more patience.
Essentially, I made the same journey as Eric did. I started out strongly negative. In fact, I originally contacted the IE team because I was concerned about what was back then called "super-standards mode", and I hoped to convince them to drop the idea.
Instead, they convinced me.
When the IE team explained the purpose and working of the switch, I gradually became aware that it is the best possible solution to a knotty problem. Not the ideal solution—certainly not from a standards-aware web developer's point of view—but the best practical one.
I won't talk about practicalities, though. Such arguments are currently out of fashion.
The most important solid argument against the versioning switch is that the default behaviour is wrong.
People who want to keep their sites locked in IE7, so the argument runs, should be required to add a
<meta> switch. That would allow standards-aware web developers to do nothing in order to retain the benefits of forward compatibility.
Jeremy was the first to raise this point, and he was quickly seconded by a whole host of bloggers. Jeremy wrote:
I think that the
X-UA-Compatibleheader is a great idea. It's great for Microsoft. It's great for Microsoft's customers. But the default behaviour is wrong, wrong, wrong!
I interpret Jeremy's post as "If somebody can persuade me that the default behaviour is a good idea, I'll support the switch". Challenge duly taken.
Let's first state the obvious: somebody will have to add a switch. Either standards-aware web developers will have to add it to engage IE8 mode, or unaware developers will have to add it to engage IE7 mode.
Now who's better equipped to understand the switch and all that it entails: the standards-aware web developer who knows his CSS and browser tricks inside-out and follows the news eagerly, or the unaware web developer who by definition is unaware of everything?
We are standards-aware web developers. We like to contrast ourselves to people who don't know what they're doing because we understand our doctypes and
floats. We think of our ways as better than those based on tables instead of CSS.
If that's true (and this assumption underlies the entire current discussion), we should also consider the flip side of that superiority.
Noblesse oblige. Since we know more and can do more and better things with web sites, more is expected of us. If our ways are so much better, we should shoulder more responsibilities than those whose ways are wrong. Our shoulders are fit to bear these burdens; theirs aren't.
Being standards-aware web developers means that we take the more difficult, but (so we passionately maintain) more rewarding and more correct road. So let's take it and let's not complain about the extra work.
Our pride requires no less.
Besides, so the argument continues, if the switch's default would engage IE7 mode we'd lose the benefits of forward compatibility. This is totally correct.
My take is: so what?
Forward compatibility is not a web standard. It's a theory—a simplified description of reality that helped us choose the right approach for building web sites.
Who exactly promised us eternal forward compatibility? W3C didn't. Browser vendors didn't.
The web developers who created the idea of forward compatibility assumed that it would work forever because that assumption made sense at the time they were working.
Their efforts and ideas are to be applauded, and they certainly helped us along, but when all's said and done forward compatibility has never been more than a theory.
Now it turns out to be a theory that may not describe reality perfectly.
When I was in university I learned that whenever a theory doesn't match reality, the theory should be altered. So it looks as if the theory of forward compatibility will have to be changed.
What's the problem with that? Are we standardistas so intellectually impoverished that we cannot create a new theory of making web sites when we need one?
I beg leave to doubt it. We've got plenty of very smart people on board who will not only be able to come up with an alternative theory, but who will even like the challenge.
So let's search for a new theory. It promises to be fun.
(Web developers can retain forward compatibility by using the
edge value, which was inserted exactly for this purpose. For reasons I don't quite understand, suggesting this course of action is like cursing in church at the moment. So be it. The sole avenue of retaining forward compatibility has been closed by majority vote, then.)
So I believe that the onus of implementing the switch should rest on those shoulders best able to bear it: those of us standards-aware web developers. Unaware web developers need all the help they can get; that's why the default favours them.
In addition I believe that we should say goodbye to the theory of forward compatibility instead of requiring reality to match it. It has helped us mightily in the past, but that's no reason to remain attached to it forever.
No, it won't be easy, but nobody ever promised it would.
We signed up for the duration. So let's get on with it.
I’m speaking at the following conferences:
Comments are closed.