IE Version Targeting

There has been debate with volleys from both sides of the web design community the past few weeks regarding a Microsoft proposal for a new meta tag to set the default rendering behaviour of future version of Internet Explorer (IE). What does this mean for the smaller web site owner? My clients tend to fall into that category so I thought I would explain the issue in less technical terms (although I’ve perhaps failed at that).

You see, Microsoft’s IE has lagged behind its competitors in standards support, largely due to the lack of development between 2001’s IE6 and 2007’s IE7. With IE7, Microsoft brought greater standards support, but broke many web pages coded to rely on Microsoft’s previous rendering in IE6 when viewed in IE7. Without getting too technical, web page composers could code their pages to based on IE6’s behaviour, and if IE was not the only possible browser (as it may be in a corporate Intranet), code also for other browsers. When IE7 was introduced, aligning its rendering closer to the standards provided by the W3 consortium, pages composed the IE6 way would break, displaying incorrectly in IE7 since it no longer followed those rendering rules.

The Microsoft proposal is meant to prevent this from happening for future releases of the IE browser. The debate is over whether the feature should be a default to opt-in by doing nothing, or an opt-in by adding a tag or header value to a page. Microsoft wants any page not containing the new meta tag to default to IE7 rendering behaviour. That means that any page without the special tag would render as if it was IE7, in IE8, IE9 or even IE100. Any future capabilities of a new browser would not be seen on screen if the page composer forgot or omitted the new meta tag.

On the other side of the debate are the web designers and developers, particularly a group that have backed standards support across all browsers to make their jobs less difficult. They don’t believe that the opt-in method helps this cause. Instead, it leaves pages without this markup rendering as IE7 does now, which is not quite up to the standards support of other browsers. They believe, simply, that if a page is missing the proposed tag, it should render to the latest engine of the browser (IE8, IE9, etc.) Those who wish to freeze the behaviour of their pages should have to insert the special code, while the rest of the composers can continue knowing they have tested and accounted for browser differences.

From Microsoft’s perspective, it is purely a business decision. The IE7 upgrade did not go well when it broke some sites of their customers, who had to adjust their code to correct the issue. This proposal is simply to prevent that from happening again. Their customers are in a “do nothing, nothing breaks” position. From a designer’s perspective, it is just another proprietary piece of markup forced upon them to correct problems with Microsoft’s faulty browser. They have seen it before. In 1999, a DOCTYPE declaration was proposed to deal with different implementations of the box model specification for layout between IE and the rest of the browsers. This declaration allowed composers to choose IE’s old “quirks” mode rendering, or standards mode with the introduction of IE6, with other browsers adopting “quirks” mode to be compatible with IE, the dominant browser at the time.

I see different perspectives on this issue. As someone who has fought with code trying to get rendering to appear correctly in IE, I just want a widely adopted IE browser that fully supports standards so sites can be coded once. I want Microsoft to continue to develop their browser, and support standards, as they still hold the largest market share. From my early experiences learning about the DOCTYPE and standards and quirks mode, I had questions how Microsoft could catch up and not break things. Their so-called standards mode in IE6 was not close to following the specifications, with many hacks needed to get around the rendering issues. When these were fixed, it was obvious that the “standards” DOCTYPE would display differently between browsers.

I remember when I first started to seriously delve in web development, I was baffled by the different ways my page would display in different browsers (and I was committed to it working everywhere). With research, I discovered quirks and standards modes and went looking for the switch in IE’s options to put it in standards modes. Only now this seems silly, but after I realized that the DOCTYPE controlled the rendering mode, I was on my way to supporting standards and struggling with IE’s frustrating bugs. Many alternative proposals have been declared for this issue, from Microsoft changing it’s web server to blocking IE visitors to new DOCTYPE switches, none very practical. Sometimes I wish it would be as simple as an option in IE, but Microsoft will not leave the option in the hands of the browser; it must be in the control of the composer.

This proposal will be implemented by Microsoft I am sure. Therefore, watch for the introduction of IE8 and test your site. The best forward-looking stance for public web sites is to code to standards, target CSS to IE version when necessary, test in all modern browsers and see how this plays out. If implemented, you may need your administrator to make a change to avoid locking in your clients to a dead browser that still happens to have the largest market share.

Update: Not so sure any more. See comment below.

1 Thought.

  1. I never saw that one coming. Microsoft reversed their planned policy today, stating that they will have IE8 interpret sites in the most standard way possible. They will focus on educating their IE customers on both standards and the changes coming with IE8 and site owners will have the ability to add the meta or HTTP header to have the site render as in IE7. The announcement at the IEBlog linked above has a very good explanation of the issue and history if you are interested in getting a clearer understanding of standards support in browsers.

    This only goes to show how far Microsoft has come, listening to the whole web community in this case and moving toward shared, adopted standards rather than proprietary enhancements. I have to give them full credit for doing today what I don’t believe they would have done five years ago.

Comments are closed.