IE8 to include version targeting

I so called it. Back in December, I gave my predictions and on the list was version targeting using the meta element. I even said it'd be using http-equiv.

Aaron Gustafson has an article on A List Apart entitled Beyond DOCTYPE that talks about a Internet Explorer's new approach to targeting rendering engines. Like a charset declaration, the X-UA-Compatible declaration can be declared using a meta tag or via HTTP headers, meaning that flipping the switch for all pages on a server to support new browsers will be a 5 minute process.

Here's what the meta tag would look like:

<meta http-equiv="X-UA-Compatible" content="IE=8" />
<meta http-equiv="X-UA-Compatible" content="IE=8;FF=3;OtherUA=4" />

Although Internet Explorer is first out of the gate to support this, it was designed to be agnostic, allowing other browser developers to use this same approach of version targeting.

Why do we need targeting?

The biggest reason is support for legacy web sites. If you think version targeting like this is something new, it's not. We already have a basic opt-in approach to version targeting: the DOCTYPE switch. The new X-UA-Compatible declaration just takes it to another level.

The fact is, as each new browser comes out and fixes bugs from older versions, our sites need to be revisited. Until we have a chance to do so, our sites shouldn't break. Remember, this isn't about us, the developers, but about the end users who have to visit and use these sites day-to-day. Upgrading their browser shouldn't break the web.

I don't want to target

If you decide to do nothing then the sites you design for Internet Explorer will continue to pretend it's IE7. Or, if you didn't use a doctype, it'll pretend it's IE5.5 (I'm guessing here since this is the last version before the doctype switch).

Alternatively, if you want to make sure your pages always use the most recent rendering engine, regardless, then you can specify that it always uses the latest version.

<meta http-equiv="X-UA-Compatible" content="IE=edge" />

What still isn't clear for me is how to specify the latest of every browser. Does OtherUA=edge work for all browsers if not specifically mentioned? I'm sure this stuff will get sorted out before long.

I, for one, welcome our new X-UA-Compatible overlords.

Published January 22, 2008
Categorized as Browsers
Short URL: https://snook.ca/s/867

Conversation

42 Comments · RSS feed
Jeff L said on January 22, 2008

awfully nervous....good concept but there is a LOT left to be fleshed out.

Eric Eggert said on January 22, 2008

Yes, I really like to have dozens of UA noted there. We’re doing web standards, not Browser specific code. This is basically useless. Websites don’t break in standards compliant browsers if they are designed according to the spec. Else Firefox, Opera and every other major browser would have introduced such a concept from the beginning.

nogg3r5 said on January 22, 2008

Surely it would be better for every browser to render html in the same way. That way designers dont have to guess at how things will display!

Nate Klaiber said on January 22, 2008

I must say, I am not too excited about it. I have read over it a couple of times, trying to get myself excited - but I just end up thinking how backwards it is.

Todd Rafferty said on January 22, 2008

You should probably also mention that Microsoft is supposedly forcing everyone still using IE6 to IE7. Not sure if worrying about IE 5 or lower is even worth it (I guess there's still a lot of win98 users out there still).

http://www.infoworld.com/archives/emailPrint.jsp?R=printThis&A=/article/08/01/17/Microsoft-warns-businesses-of-autoupdate-to-IE7_1.html

Jonathan Snook said on January 22, 2008

@Eric: which standards are those? CSS 1, 2.0, 2.1 or 3.0? And as much as we bash on IE, it affects us the most because it has the largest install base. I once had to use tables on a site because Safari didn't support what I wanted. Of course, it's progressed now to the point where I don't have to worry about it but there is a great deal of legacy code that we have no control over.

Besides, it'll take you 5 minutes to set your server to never have to worry about it again (by setting the header to edge). Just set it and forget it.

Lance Fisher said on January 22, 2008

@nogg3r5, every browser rendering the same would be nice, but unfortunately we don't live in a perfect world. I don't think this will ever happen, especially as new standards are released. No one will get HTML 5 or CSS 3 right on the first try, and it is highly unlikely that they will all get it wrong in the same way.

I think this is a good path to go down, and I hope other browser developers decide to support this as well. If a client hires me to build a website, I don't want to have to check up on it every few years to make sure it doesn't explode with a new browser version, and I would say that most businesses don't want to hire a developer for that reason either. If browsers can respect older pages, then it gives us developers a firm foundation on which to build.

My only concern is browser bloat, but I would rather see that than webpage bloat which seems to be where we have been heading with CSS hacks, Javascript browser sniffing, and conditional comments.

Brad Dielman said on January 22, 2008

@Nate - I agree with your assumption on this, it just seems wrong.

@Snook - If I have to do it, looks like I'll be using 'edge'. At least we have that option.

Jonathan Snook said on January 22, 2008

And to all those who think this is a bad idea, will you put pressure on the other browsers to drop quirks mode support?

Nate Klaiber said on January 22, 2008

@Snook - the other issue is, just as with other standards, its requires people to be able to set the header to 'edge' if they so wanted. This requires them to have knowledge to change it (not everyone understands), privileges to change it (some might not have access).

So regardless of which way you look at it, it requires the developers to change something. Only now, we are putting more trust and faith in the browsers to implement this consistently. I feel like we have been down this path before.

Honestly, I can't come with a solution - there just seem to be so many barriers to both sides (even web standards). I just don't feel right that this is a 'solution.'

Neal G said on January 22, 2008

Many angry people are missing the fact here, that IE wants to do this so they can start SUPPORTING STANDARDS more aggressively. Currently they are reluctant to do so because they don't want to break old websites. It could be possible that with IE9, it could be completely on the same level with Firefox and the rest because they aggressively updated the rendering engine etc.

This whole ordeal is quite funny to me considering the top "experts" in the field are supporting it (and partially microsoft) while all the lowly developers are turning their backs. Sort of against the trend for once.

Matt Wilcox said on January 22, 2008

I'm with you on this one, I think it's a great idea, and the drawbacks are nothing major.

More of my thoughts:
http://mattwilcox.net/archive/entry/id/956/

Matt Wilcox said on January 22, 2008

"the other issue is, just as with other standards, its requires people to be able to set the header to 'edge' if they so wanted. This requires them to have knowledge to change it (not everyone understands), privileges to change it (some might not have access)."

If the people do not know about EDGE then they are unlikely to be the people that code with standards, or want that behaviour anyway. As I see it this system is brilliant for ignorant web developers. When they test and build their website they will be viewing it in a DOCTYPE derived mode, so either 'quirks' or 'IE7'. Well, their ignorance won't matter to anyone because their page will always render properly, even if they author crap code but have a valid doctype (say someone developing in Dreamweaver...). And if they want to take advantage of the new-shiny they'll have to learn to code properly.

Other people who are not ignorant of the issue can set EDGE. So they win too.

Win/win/win, everywhere.

Shaun Andrews said on January 22, 2008

"I so called it"

When will you be predicting the NYS Lotto? Please keep me informed of all future predictions.

Thanks.

Anonymous said on January 22, 2008

Jonathan, I definately agree. Something is required to allow future browsers to break free from earlier editions featuring poor standards support. Allowing sites to set the rendering engine that should be used negates the need for later rendering engines to compromise for the sake of supporting older sites. This seems to be a reasonable solution.

pauldwaite said on January 22, 2008

its requires people to be able to set the header to 'edge' if they so wanted

But if they don’t, then the worst that will happen is their site, when rendered in Internet Explorer, will be rendered as if it’s Internet Explorer 7. If they don’t have enough control over the mark-up to be able to set a meta element, I doubt IE 7’s rendering will be an issue for them.

gRegor said on January 22, 2008

It makes zero sense to me that I should have to add a meta element to make Browser X version Y render as itself instead of an earlier version. What on earth??

Matt Wilcox said on January 22, 2008

I think this is really good for the web. Because I think the new default of 'stay as IE7 when no meta tag found' will enhance the uptake of web standards. Because every ignorant developer on earth is now going to be permanently stuck with IE7 rendering and behaviour. They will never get to use any of the new-shiny of IE8 and above if they don't know to include that meta tag. They won't know to include that meta tag until they go away and learn about web standards.

If I could, I'd have every browser on earth fall back to the current DOCTYPE switcher mode, and current render engines, if any part of the page did not validate. That'd stop ignorant developers simply slinging in the meta tag and carrying on producing tag-soup. It would force valid pages if you want to use CSS3 or the new ECMAScript. And all the while leaving the rest of the web totally unbroken.

Nate Klaiber said on January 22, 2008

@pauldwaite and @matt wilcox - I understand what you are both saying. I understand the default behavior (and do not like it). I understand that if people don't know about edge, then they probably aren't building to standards (still a bad argument for those who are just learning standards - maybe even a turn off). This all just seems like major hackery to me. I know we don't live in a perfect world and things will never be perfect, but this 'solution' doesn't seem like much of a solution to me.

Maybe it's my lack of trust in MS, that they now have control over the rendering per a meta tag (or server configuration). As gRegor says, it makes no sense.

Again, all my personal opinion and I have no solution, I just fail to see this as any kind of solution.

Tom Sieron said on January 22, 2008

How about declaring the standard (eg. HTML4.1 strict; CSS 2.1) which the website creator followed instead of the browser agent? The W3C standards are specific enough. Declaring UA seems crazy - what about mobile devices, what about screen readers, exotic browsers? Why should I care about listing UAs? If I list FF3 and IE7 and forget to list some exotic browser how should it behave? Should all browsers try to imitate the mainstream ones? Why? It's like introducing quirksmode all over again.

Jonathan Snook said on January 22, 2008

@Shaun Andrews: My powers don't work that way. ;)

@gRegor: I think you're looking it as "as a developer, I have yet another thing to do to make my sites work" when you should probably be thinking "as an end user, I'm happy that things will continue to work just fine."

I'm reading things like, "catastrophic failure" and I'm thinking, take 5 minutes right now, configure your server, and move on. People are spending more time complaining than it would take to solve the problem.

Anders Ytterström said on January 22, 2008

What, exactly, is the difference in this compared to conditional comments? As far as I can see, this new feature is just another way of doing what web developers have done for years - writing specific rules for certain versions of IE (lower than 8, or lower than seven).

Will IE8 drop support for conditional comments? In that case, it's nothing left to do but to reinventing the wheel and using this new feature. If not, I do not see the point.

Adam J. McIntyre said on January 22, 2008

@Snook: I agree. It's just another one-line add to whatever you use as your "base template" upon which you build all your work.

@Tom Sieron: It does seem like there's a lot of ambiguity here. How long will it take for FireFox to support this? What if Safari/WebKit never does? Do browser vendors now need to add a bit extra code to support these old rendering engines? It will be interesting to follow.

Kasimir K said on January 22, 2008

So far I have designed to the standards - not to different browser versions.

I'd love to continue that way.

Nate Klaiber said on January 22, 2008

"I'm thinking, take 5 minutes right now, configure your server, and move on. People are spending more time complaining than it would take to solve the problem."

I can think of at least ten people (web designers) who would have no clue how to configure their servers to do this. I could also list off the majority of agencies around me that would have no clue. Honestly, they wouldn't understand one bit. This requirement of 'just update your server' just seems really silly to me. How many times and how many different browser variations will we have for this? One for IE? One for FF? One for Safari? So now - instead of cluttering up our markup with hacks to fix their broken implementations, we now have to clutter up our server config files to send the right HTTP header info. Seriously? How is that a solution to anything?

It all looks like the same pig, just different lipstick to me.

Alan Rabinowitz said on January 22, 2008

Bizarre that we have to add code to use the latest browser, shouldn't it just detect compatibility, now that would be a superior browser, one that actually knows what to do.

Carl Holmberg said on January 22, 2008

Well people didn't know about doctypes at first either but these were later auto-inserted by html-editors. Don't you think the editors will start adding this as well and what newbie webdesigner wannabe will choose anything but the "edge" setting. This is as doomed as the doctype switch was...

It's only a matter of time before we'll need something new unless we can force the developers of the html-editors to not include the feature... The only way I see is to always force standards mode and have an opt-out instead of this opt-in system.

Samuel said on January 22, 2008

Why not just use the standard, like HTML5 in the next few years. A standard created by most of the browser maker out there, as far as I know...
I think web developer should be able to tell he browser witch standard they use and their jobs (the browser) is to render it accordingly. I know that I may be dreaming.

Damjan Mozetič said on January 22, 2008

Like I said before, I don't believe this is going to work in the long run. The implementation of this backwards compatibility meta thingie will be buggy as hell, and thus useless.

Inferis said on January 23, 2008

As it stands, we'll only be needing this for IE8 now. Other browsers don't currently need it, and might never need it. But if/when they do: there's a way to do it.

It's like an explicit fallback mechanism. One that you (as a developer) can control, and not one that depends on how a specific implementation renders a hack (which are interspersed in your code -> ugly). This is much cleaner than all the CSS hacks we have now because it's explicit.

Olly said on January 23, 2008

What still isn't clear for me is how to specify the latest of every browser.

It's looking distinctly like IE will be the only browser to support the header. Today I've read posts from people representing Mozilla, Apple and Opera saying they can't see the benefit in adopting this header.

I remain unconvinced by this idea. My feeling is the default behaviour is back to front.

A major issue to me is one of education. How are MS going to get the message out to everybody developing websites now, let alone newcomers to the industry? It's bad enough helping people get their heads around the quirks/standards mode switches as they stand today.

gRegor said on January 23, 2008

@Snook Actually I'm just thinking "great, MS is doing another stupid thing that makes me have to do more to make their browser work correctly."

And as an end user, if Browser X says it can do Y, I want it to do it. It shouldn't have to rely on developers doing something extra. This is both a developer and end-user perspective.

Tom Sieron said it pretty well, I think.

Jessie said on January 23, 2008

Interesting, well done on another great prediction.
Like other posters, i'd love it if every browser would render html the same. Would make my life 10x easier!

Jeff said on January 23, 2008

@Snook:

Sorry Snook, but I have to disagree you and agree with Jeremy Keith here in that if you let MS say this is the only way they can support the spec it is letting the tail wag the dog and that's just not right.

Since when does MS have the kind of power to get to dictate standards support to everyone else? Isn't that exactly what they are trying to do here?

Now sure, it’s a five minute job to change the server headers, but why should you have to, especially when at present it’s just for Internet Explorer? Why is IE so damned special? Market share again? If so then isn’t that all the more reason to hold their toes to the fire to support to current spec instead of creating their own like they did for OOXML?

Also, if the content in those HTML 1, 2, and 3.2 pages is that important to preserve then screen scrape it, park in an XML file, and just be done with it. If it’s the graphics you're after then make screen captures till your fingers hurt for all I care and again, convert it and store in an XML file or in a database. Either way the content is preserved in a format that is usable. Until the next time we run into this problem (which should be within the next five years anyway).

You asked if someone earlier if they would pressure the other browser vendors to live up to the spec just like they were advocating MS should, my answer would be “Damn straight!” because the other browser vendors are all trying to do that as we speak, WITHOUT having to use version locking like the IE Team is suggesting.

As to the backward compatibility argument, If the only browser your app will run in is IE 4 then don’t you think its time you upgraded? And you’ll say “But upgrading costs money” Sure it does, but a better, standards compliant browser is a free download and updating that application from Classic ASP to ASP.NET or PHP (or heaven forbid COBOL) can be done relatively painlessly for a modest investment and you're old app can live in place for the time it would take to outsource your upgrade.

My point is I think an awful lot more scholarly debate actually needs to go on among all parties involved before we saddle up this pony riding headlong once more into the breach dear friends and damned be everyone else.

Jonathan Snook said on January 23, 2008

@Jeff: First of all, thanks for such a lengthy reply. That was a whole blog post right there! :)

Since Microsoft makes the browser, they can do what they want. Honestly, they can. Every browser developer can and in fact, have. If you don't like it, don't use it. The fact of the matter is, the majority of web users still use Internet Explorer more than any other browser. As a web developer, I cater to what my clients want and if they want IE support (warts and all), I give it to them. We've done so much more work to cater to IE's deficiencies that I wonder if this one extra line is just the straw that broke the developer's back.

Anyways, let me offer up a possible scenario here: Let's say I've bought a big enterprise CMS. It's web-based but only works in IE7. This thing cost the company at least $100k, not including all the support required to install and train for this application. A new version of IE comes out and now I can't use the CMS to update the site. Even worse, all the code this CMS spit out to my customers doesn't work either and I've got plenty of support calls to prove it. The CMS doesn't have a new version available yet...what do I do? (and make sure your answer means I'm not spending another $100k+ to solve the problem.)

This is a very real scenario that played itself out very nicely when IE7 came out. And guess what companies did? They stayed with IE6 because it worked. (This is just one of the reasons why the uptake on IE7 has been so slow.) Now, if you tell me that IE8 won't have this problem then hallelujah...let me roll out that browser to my entire company of 1000 people. And guess what, your site that you built with all the latest cool web standards but yes, had to add one line of code, now works quite nicely.

I still think this is the best solution and we can debate it until the cows come home but I'd rather see Microsoft get their new browser with a rendering engine that meets Acid2 out to the masses.

Barney Scott said on January 24, 2008

I think that there are a few reasons why people have been so negative about this proposal.

1) I'll start with the obvious first, Microsoft is suggesting it. Now it's all well and good saying that people should give it a chance and that just because Microsoft are suggesting it shouldn't be written off immediately. The problem is that nobody trusts them and for good reason too, they have screwed over their end users and developers time and time again. Every move they have made into the standards world seems to be an attempt to destroy the competition by owning the standard. This may be a completely innocent idea from Microsoft but it is going to be a long time of nothing but good behaviour until people start trusting what they say.

2) For that last few years the mantra has been code for the standards not for a browser, adding in browser specific code has been seen as dirty. When flame wars have built up over whether CSS hacks or conditional comments are the better way to go, can you blame people for being shocked when some of the most prominent standards people turn around backed by Microsoft and say actually it's ok.

3) The way that it was announced seemed to have the traditional Microsoft air of backroom deals and shady dealings. There were explicit references to WaSP that made it seem like they were heavily involved as a group, only for a large number of them to turn around and say actually we've not heard about this before today.

4) For the last few years we have had to hack around IE's deficiencies, make special allowances, compromise the quality of our code and all this time the end users have been oblivious to the state of their favourite browser. Then Microsoft announce that IE8 passes ACID2 and we all start thinking that maybe this time it will be better, we might be able to code once and then not spend the same amount of time again fixing for IE, there is hope. Then all of that is seemingly taken away to be replaced with the rod, is it any wonder that people are pissed.

And with regards to IE8's ACID2 abilities surely they fail the test. As i understand it the test should be taken with default browser settings, and in its current state IE7 fails the test. If the new meta tag is used or the http headers are changed to fit then the test has been changed to suit one browser, which means that it is no longer ACID2. As far as i can see it then if this carries on then IE* will never pass the test as it will always be taken as IE7.

Jamie Strachan said on January 25, 2008

Remember, this isn't about us, the developers, but about the end users who have to visit and use these sites day-to-day. Upgrading their browser shouldn't break the web.

It seems like a lot of people are missing this point. As a developer, I'm trying to deliver an experience to the user and I'll work with the tools I have at my disposal to do so. If that now includes a new <meta> tag, that really doesn't seem like much of an imposition.

Microsoft has to worry about their users too and this seems like a pretty reasonable way for them to progress without alienating their install base.

Dinoboff said on January 25, 2008

Lots of people don't really understand the issue. The website that will break with IE8 (or IE9) are the one that are written with standard but assume IE is not Standard compliant and apply fixes to it.

Remember what's happen last year:
http://www.thinkvitamin.com/features/design/internet-explorer-7-were-you-ready

You can think MS has a secret plan to lock people into its products like Silverlight, but I don't see how this meta tag can fit into its evil plans.

Also, with the standards we are using today (HTML4, XHTML1 and CSS 2.1...) that are now stable, clearly, IE is the only one that need this tag. But with HTML5, JavaScript2 and CSS3 coming, other browser might need it in the feature if they start to implement them when they are not finish.

Jeff said on January 28, 2008

@Snook

I see your point, but still, the way MS handled this whole debacle leads one to believe they haven't learned anything from their earlier mistakes despite what Chris Wilson says. Why must they always do everything so clandestine, blackbag and covert? I know its their option to do so, but its an option that just doesn't make sense.

You think they'd want the development community to know "Hey we're working on a new version and we'd like your help!" After all, just look at how much community support there is for Firefox and Webkit.

I think if they'd be more open and more forthocming with the developer community as a whole I bet that it would go a LONG way to restoring the trust developers now lack in and for MS and IE.

Stuart Steel said on January 30, 2008

What I hate is its just another level of complexity to deal with, and another level to explain to clients. There are always some hidden costs, that we don't even realise ourselves.

As an example I've been consulting with a large corporate client for several years on a web application. For purely historical reasons it never used a doctype so ran in quirks mode, with a purely IE userbase. To the client adding the doctype was an expense with no payoff, so it never happened. But more recently we discovered that the quirks mode rendering time was 5-6 times slower than standards compliant mode. Their app has been unfairly been perceived as slow as a result for years.

Johnny said on January 30, 2008

One thing I am dreading seeing "Best Viewed in IE7" I sincerely hope it's not a return the bad old days!

hoopskier said on January 30, 2008

@TomSieron: "How about declaring the standard (eg. HTML4.1 strict; CSS 2.1) which the website creator followed instead of the browser agent?"

Because user agents have bugs in how they implement the standard. Let's say Microsoft claims 100% CSS 2.1 compliance in IE8, but then after IE8 ships they find bugs in it. When IE9 ships with those fixes, this could cause sites targeted at IE8 to now break. This same scenario happens with other browsers today -- it's just that the perception of the breakage depends on the size and type of your user base.

Until every browser is bug free (which, since code is written by humans, is quite a long time), there will always be compliance bug fixes, which all have the potential to cause disruption. Targeting a UA version, not a spec, is required to minimize this disruption.

Sorry, comments are closed for this post. If you have any further questions or comments, feel free to send them to me directly.