Mar 02 2008 at 9:57pm

IE8 version targetting: I don’t buy it either

Okay, okay, I’m sure you’ve read enough about the whole IE 8 meta tag debacle. I understand, so have I. So feel free to stop reading. This is yet another mostly negative opinion (as could be expected, right?). And, yes, I’m a few weeks late to the discussion. Bill Gates was visiting, it took up a lot of my time. Now isn’t that ironic?

Opinions I like

And the TWF discussion thread.

Don’t piss off the clients!

I understand Microsoft’s point on this. I’ve been there, in a modest way. You don’t want to do anything that makes your clients angry, especially if they’re going to make a lot of noise about it. Apparently this happened with IE 7 and the manageria at MS don’t want to go through that again. I understand. It sucks to take a beating like that.

But, on the other hand, MS has been taking a lot of pains to kiss up to developers lately. What about that? Well, in this case they went straight to the most respected web developers site and got them to say some nice things about it.

What exactly is going to fall apart so badly?

They don’t even have an alpha version out yet. IE 7 fixed most of the worst CSS bugs. And even if something was a little different it certainly wouldn’t cause sites to become completely unusable. Scripting I honestly don’t know that much about. When I first read about this issue I was under the impression that it was just CSS that was going to be impacted but Zeldman says otherwise.

Jeremy Keith expands more on this in his ALA article. I agree that it’s strange to talk about doing all this before anyone has an idea of how severe the damage would be.

And even so, if it’s just CSS or just scripting or either, wouldn’t it be better to target that separately? So, to have an option to say that this site uses the IE 7 scripting mode?

I also strongly agree that if they’re going to be the meta tag it should work in the opposite way. That is, the meta tag could be added if you want your site to stay in IE 7 mode and not the other way around.

At TWF Gary brought up the problem with active X controls which I haven’t seen talked about too much elsewhere. This may be where the real problem lies. So why do we need to break CSS to allow these old active X controls to keep working?

I’m still a bit confused about this because even the MS announcement and 3 out of 4 of the ALA articles are mostly talking about CSS.

Quotes and notes

Jeremy Keith says:

This is gobsmackingly audacious.

Right on!

Eric Meyer says:

Developers have been forced to conform to past browsers’ behaviors while making educated guesses about what future browsers would do.

But we do know what future browsers will do. It’s in the spec. CSS 1 is CSS 1 whether it’s 2006 or 2015. I can’t recall ever having to make a change to a site when a new version of Opera or Firefox came out.

Meyer also says that:

Forward-compatible development and its cousin, progressive enhancement, were necessary and proper because they were the only hope we had of sites continuing to work into the future.

The only hope? More like the correct assumption. I develop under HTML 4 and CSS 2 knowing it will work forever. And this is where it gets scary. If browsers assume that developers are going to lock in to a specific version of their browser then they don’t have to try to implement the specs correctly, with forwards compatibility in mind. In fact, they can toy around with whatever they want, knowing that developers are tied to their versions, not to any standard. Before you know it we’re back in the 90’s when different browsers had completely different implementations and their own proprietary tags.

Aaron Gustafson recommends not using the IE8-edge modifier because “even Eric Meyer can’t predict layout or scripting bugs that may be accidentally introduced by a new browser version.” Oh, come on. You mean browser makers are just going to change things that are already implemented correctly? Unlikely. Okay, so I’d be unlikely to use that on a really mainstram website (like my work sites), but I wouldn’t hesitate on others. Although, on really experimental sites I’d be more likely to just leave it out altogether to prove a point (IE sux0rs!).

Coding with “reckless abandon”? What? Have we suddenly forgotten how standards work?

Some alternatives

There are many other things that MS could have done to mitigate this:

  • Do another level of doctype switching (Roger Johansson has suggested this and I thought of it as well. Not ideal but certainly better than a meta tag)
  • Release IE 7 as a standalone, so anyone dependent on apps that only work in 7 can continue to use them until the apps are upgraded to v. 8
  • Work with site developers to help them upgrade their sites to IE 8. I think this would be a great move - Opera does this all the time. I don’t recall seeing anything around the IE 7 release from MS detailing the problems that developers may encounter and how to fix them. Providing development support would possibly be more cost effective than attempting to build a browser that perpetually supports multiple rendering modes. Wouldn’t their clients love it if Microsoft paid some developers to fix their sites for them?
  • Release more betas, sooner and more often so developers can test further ahead of time and bugs can be fixed faster. In addition, educate developers about what will be changing in IE 8 as soon as possible so appropriate changes can be made.
  • As brought up by Gary, announce an end of life date for IE 7, say, 5 years ahead, that would give developers plenty of time to move old applications to standards.

Does Microsoft want sites to only work in their browser?

Liam and I were talking about this one night and it does make sense. Applications that are tied in to using IE only forever are good for Microsoft. They probably really like stuff like that because it forces a whole lot of people to use IE, which means they’re also using Windows.

So really, they don’t want developers to use standards, they want them to do stuff the IE-only way. This meta tag obscures proper standards in IE — they’re only there if you know how to access them. Which means more people can continue on making stuff that only works in IE. Just a conspiracy theory :)

Liam writes:

My bet is they’re trying to avoid standards compliance — retaining the locked-in status quo — whilst still appearing to be doing the right thing for PR purposes.

When looked at in this way things start making much more sense: people can carry on writing non-standard code, working in the dark of vendor lockin. It also makes coding with standards confusing for beginners (bonus point for Microsoft!).

If you haven’t already you should read some of Liam’s comments about OOXML. This is something web developers seem to be largely unaware of but it says a lot about how MS really feels about open standards despite their newfound “commitment” to web standards.

If it was just temporary

I wouldn’t have such a huge problem with it if this was a one time thing. Okay, you can lock into IE 7 or IE 8 rendering if you want to. But having to put one in for every site for every browser version for ever and ever? Nuh-uh.

Really, it’s just wrong

Standards are standards are standards. They work now, they work next year, they work in 10 years. Always the same way. You don’t have to say which browser you’re targetting because you’ve already said which version of html/xhtml you’re using. CSS doesn’t require version targetting since it’s always forwards compatible.

The web standards movement started in 2001 (if not earlier). That was 7 years ago. If you’re still not developing to standards then you just haven’t been paying attention.

Comments RSS

2 Responses to “IE8 version targetting: I don’t buy it either”

  1. Looks like the IE team read your blog post!

    http://blogs.msdn.com/ie/archive/2008/03/03/microsoft-s-interoperability-principles-and-ie8.aspx

    They actually caved in to pressure, excellent.

  2. Whew! Well wasn’t that a lot of broo-ha-ha for nothing.

    How does one spell broo-ha-ha anyway? Brew-ha-ha? Brewhaha? Broohaha?

Leave a Comment


(will not be published) (required)