IE8: let’s take a step back

I’ve read a lot of what had to be read on the IE8 controversy.

For future reference, let me sum it up.

Version targeting

When IE7 went out, although it was considered a show of good will on Microsoft’s part from the standardistas (among which I stand), sites broke. Not like “ceased to work”, but like “displayed ugly things and were seen by people who don’t know squat about how things work but want to see their websites on Tuesday the way they looked on Monday”.

So, rumor has it that this step forward was not considered a success internally.

To be able to both keep up with getting closer to the standards and please their client base (some of which are big enough to be heard at the top of Microsoft when they complain), the MS IE team came up with the idea of version targeting, which can be summed up as: any website not saying anything special in its HTML would be displayed with an internal IE7 engine. Any website that said “I want to be displayed like IE8 can” would be displayed using IE8’s engine, and so on.

Want to live on the edge? Then you can specify the IE version as “edge”.

Thus, the IE team can develop closer to standards and still, if you do nothing on your pages, display your crummy old bug-abiding HTML as you meant to display it, you who did not have sufficient culture, time or money to do otherwise than code for IE’s bugs.

The trouble with version targeting

OK, so say you want to abide to web standards of the day. You have to add a meta tag or a server header so that IE knows you mean business.

Some argue that it’s overhead: why would a standards-oriented developer bear the chore of adding meta or header information when obviously, they’re doing the right(ish) thing? I agree with them. I spend an incredible lot of time doing my technical watch, reading blogs, testing stuff, trying to stay at the edge, why should I accommodate yet another browser-specific hack (because in a way it’s what it is).

Some others say that this idea is interesting: after all, we know that a lot of web pages, both on intranets and on personal web sites, aren’t really up to par with what can be expected of quality web developers. But their take on the subject is that the browser should not be compatible downwards but upwards to its current version. I agree with them. How on earth can you expect me to keep doing stuff the old way in addition to doing stuff as modern as possible because most of the other browsers can?

Yet some others say that as it is, it’s a good idea: the lesser of many evils. Add a header on your server and you’re done. After all, it’s your daily life as a web developer to overcome difficulties with browser rendering differences. I agree with them. This additional information is not so much work, and if I don’t have my hands on the server configuration, I’ll add a meta and I’ll be done.

My stand

You know what? First I was shocked. Then I thought that clever people like Chris Wilson, Eric Meyer, Aaron Gustafson, Jeffrey Zeldman can’t be so wrong as to propose such a solution without having thought a lot about it. I understood that it needed some very thorough thinking.

So I did give it a lot of thought. I still can’t find a stand on what opinion should prevail. Obviously I see all parts of the tale and no, it’s not an easy decision. I love standards but I’m a pragmatist and I see where all these people come from, I’ve travelled along with them, albeit silently.

My idea is that in a few years, when for example not so many sites rely on the IE6 rendering bugs, when a majority of people who are still in the field find that the box model is a great model, this won’t matter so much.

Wild guess: I’m expecting Microsoft to drop version targeting from their rendering engine after a few iterations (IE9, IE10 maybe), when companies have had enough time to evolve their intranets. It’s a slow, painful process (I should know as I belong to one of those big, slow movers), but it does happen.

After all, in 1999 we were pulling our hair off with the fear that Netscape 5 would come out and it was said to support neither document.layers nor document.all. We thought “What the hell, yet another forking to be added to all our Javascript!” And look where we are now. In retrospect we shouldn’t have worried so much. (and yes, I know it’s not the same thing at all so don’t spam comments with your insights on how it’s just not the same thing).

As professionals we’ve always dealt with browser incoherences at some level. As standardistas we tell people that they should prepare for great and less-than-great renderings according to their browsers. We tell them that it is to be expected. And we believe in what we tell them, of course.

But in the end, when we work for the clients who pay, we do what’s necessary to be as consistent as possible across all the major browsers (at the time I’m writing this means IE6, IE7, Firefox, and if we have bonus time we’ll check Safari and Opera). Because our clients know nothing about browser inconsistencies, CSS2.1 implementation, DOM limitations. They know about what they see, and what they see is this: oh, look, the site you’re showing is way different in this browser and that one.

We use conditional comments, we have taken profit from CSS parsing bugs, etc. Don’t tell me you never used * html when you needed to target IE.

Let us take a step back for a moment and look at the bigger picture:

• The day before yesterday we used CSS hacks to target some browsers — or CSS constructs not understood by some browsers, like html > body that I’m using on this very site at every other line in my CSS because IE6 was too painful to cater to.
• Yesterday we used conditional comments, be they in HTML or in Javascript. Very efficient way for the IE team to help us get closer to standards.
• Now we’ll have to deal with version targeting. No matter what some people hope, I don’t think this annoucement was for the sake of “hey community, what do you think?” I think it’s more like when MS had to change the way Flash plugins are inserted in HTML to accomodate the Eolas case. This is what we’ll have to deal with.

Maybe there is no iceberg

All this said, I’d wish to see what Jeremy Keith proposes to Microsoft: ship a beta with no version targeting and let us figure out if it’s as catastrophic as we’re told.

In my company (200,000 people, I hear), any software migration is not done on a whim. It has to be thoroughly tested for compatibility with all major applications before being considered safe. So we’re just only now reviewing IE7 for our desktops.

Guess what? The projects that are standards-oriented, the projects who know about the html > body dirty little secret, the projects who know that if you’re doing any JS forking you should first do the most standard thing and then accomodate less standard browsers, they are the ones rejoicing because they have no blocking points when testing IE7.

An example: when you want to access the for attribute of a label, you have to do this at the moment:

1. Hi browser, do you know element.getAttribute? Then please element.getAttribute("for") for the current label object I’m targeting.
2. Oh, you think it’s a element.htmlFor property you need? You joker, wouldn’t you be good ol’IE?

And not the other way around: you won’t ask the browser for the htmlFor property first.

We’re experienced developers now. We know the right order to do things, most of the time (or hope we do).

Other developers, those who don’t want to see the truth and the way history is going, will have a few years until IE9 comes out. Maybe by this time they will have evolved, or moved to another field of activity.

Living on the edge

I don’t know why it’s been deemed “not advised”, but I’m considering living on the edge (I’m so wild, eh?), coding for the latest version of browsers and accommodating difficulties in older browsers for as long as they represent a significant market share.

Which, come to think of it, is exactly what we’ve done for the last ten years.