Version Targeting For IE8, Developer Wars, My Thoughts

Posted on Wednesday, January 23rd, 2008

Change is afoot. Every web developers’ favourite publication, A List Apart, has split the split them into three groups today, the content, the annoyed or the confused. The cause of this: Aaron Gustafson’s introduction to Internet Explorer 8’s version targeting feature and Eric Meyer’s thinking process in response to the idea. In a nutshell, from IE8 onwards the inclusion of a meta tag (or server setting) will be necessary to target the version of IE to use to render the page, defaulting to IE7 rendering if no meta tag is found (please see the article for more detail).

This has thrown the developer community into disarray as everyone tries to work out whether this is madness or genius. Jeffrey Zeldman, Jonathon Snook and Eric Meyer think it is a good thing, Jeremy Keith doesn’t, Drew McLellan distanced the whole Web Standards Project from the decision and Andy Budd thinks that IE will be the one to feel the force of the mistake. Here are my thoughts as I pass from the confused camp to one of the other two.

Breaking The Web

So what are the reasons behind this new control? Well, it all goes back to Internet Explorer’s shoddy implementation of standards in the past and the eventual turn to support standards properly more recently. IE5 used the wrong box model, IE6 was riddled with many bugs and less than half of the CSS 2.1 specification implemented and IE7 is finally on the right tracks. While this sort of progress is beneficial to the web overall, there has been a lot of pain involved with upgrades to the browser “breaking the web”. The recent upgrade to IE7 caused the most problems due to the vast improvement to standards support.

Of course, you would have thought that improving support for standards would improve the web, but where IE6 had been the standard for so long, many websites were coded to IE6 compatibility rather than W3C compatibility. When IE7 fixed the problems in IE6 it simultaneously broke those sites. (See Chris Wilson’s, of the IE team, explanation for further detail.)

Aaron’s article explains how the old method of easing between browser versions is broken now too. Declaring a DOCTYPE at the start of an HTML page would render it in the browser’s standards mode, missing that out would invoke the quirks mode that rendered sites using the incorrect box model and other legacy differences in order to keep everything running smoothly. With the pressure of web standards groups over doing things right and validating code, web editing tools have started to include DOCTYPES whether the user knew what it was or not, thus breaking the only switch the browser had to distinguish which sites could cope with the latest rendering.

Version Targeting

So it has come to this, another method of telling the browser how to render a web page and one that comes laden with a whole bunch of new problems and benefits. I tried to write down what I thought was good and bad about the idea and came up with quite a list (things are still occurring to me as I write this, it is all so fresh), so I am sharing it so you know exactly what I am thinking.

The Good

For a start, the default setting of IE7 rendering (which applies to the whole web, but for those particularly fast developers who have already updated their sites) means that an IE upgrade will never “break the web” again. This is useful for developers who don’t want to check through every site they have ever produced and fix any problems, they can set the version in which they know the sites work.

Browser sniffing, the unpredictable methods possibly used in the past need never rear its head again. As Eric Meyer said:

Version targeting reverses the emphasis of browser sniffing completely, making it “the browser checking the page to see when it was developed and making adjustments to its behavior accordingly.”

The Internet Explorer team can be set free to implement standards without worrying about all the sites that may be affected.

The Bad

Before version targeting, you had to rely on an upgrade implementing standards correctly (something that should be reasonable, but rarely is), now developers will have to rely on browser manufacturers maintaining old rendering engines correctly.

Browsers could become very bloated. Consider in 20 years time, where can reasonably expect to see IE15, by then there will be 9 different rendering engines that will be available to put into play at any time.

Progressive enhancement will become vastly stunted. The idea of providing functionality that up to date browsers will be able to use, but locking the site to rendering by the browsers you tested in disables those bits of functionality that the browsers could potentially cope with (unless the developer returns to update the meta tag).

Further Considerations

What if editing tools start adding arbitrary version targeting, like they started adding DOCTYPES? Inexperienced web developers wouldn’t know where they were or why a site created with one tool looked different to the same site created by another.

What about new standards? What will an HTML5 site look like when displayed in IE7 mode? Or HTML6? Or HTML60?

What about developer apathy? It stands to reason that the majority of websites are not strictly coded pillars of the standards community, in fact all those developers not reading A List Apart and considering this now are the ones that this sort of time and rendering freeze are aimed at. Now, if the majority of sites out there are built like this, freezing time and rendering in 2007 with IE7 then no matter how much innovation goes on in standards or IE rendering, the most used rendering engine will still be the default IE7.

What happens when you opt for a browser that a user doesn’t have? For example, say you opt for IE9 rendering and a user with IE8 visits. Do they render in IE8 or IE7 mode?

A Conclusion?

The things I worry about the most are the future, the potentially bloated browsers, maintenance of old rendering engines and behaviour when faced with future standards. Hopefully someone will be able to provide some sort of reassurance soon. The future standards question was mentioned by Eric Meyer, who said that perhaps default rendering for later versions of HTML could be switched by the DOCTYPE again, given that IE7 won’t have much of an idea. This is something I would definitely support as it would retain an incentive to those who want to use the new technology available but don’t know all the intricate details.

There is one thing I haven’t mentioned yet. The “edge” keyword, to force the browser to use its latest rendering engine. This could go one of two ways, either everyone will use it and the targeting will become as defunct as DOCTYPE switching or no-one will and progressive enhancement will be dead. I just don’t know which will happen.

Tentatively… Yes

After all this thinking, all this writing, I think that version targeting in Internet Explorer could be a good thing. I will give it my tentative support for now, while waiting to hear more about its implementation and details. However, for other, standards compliant browsers, I don’t think it should be adopted. As I made clear at the start of this article, upgrades to IE7 only broke the web because IE6 did it so wrong for such a long time. Never has anyone complained of Firefox, Opera or Safari breaking the web when they upgrade, no-one is panicking or advising developers to check all their sites in the Firefox 3 beta right now, because they have it mostly right already and are only adding features. Progressive enhancement can live on for these browsers, they can continue to implement the standards as they were meant to be, while supporting the older ones too.

Internet Explorer has always been a special case when compared to the standards. Sadly, it remains the most popular browser out there, leaving us devoting precious time to fix its quirks. Maybe one day, when the oldest browser is IE10 and all standards are supported well by all browsers we can drop this targeting again, focusing instead on progressive enhancement and encouraging people to upgrade not because it makes developing easier, but because they get to use all the cool things afforded by current technology.

Until then, at least we can guarantee that IE8 won’t break anything straight away!

More of my thoughts on browser targeting after the dust started to settle a bit.

If you enjoyed this post, why not subscribe to Unintentionally Blank

Posted in Articles, Browsers | Trackback | Leave a comment


Comments

  1. 1January 23rd, 2008 at 4:53 pm

    Tim Says:

    My immediate reaction to reading the ALA articles was that version targeting looks like it was put in place to put a stop to bosses coming up to developers and saying “why doesn’t our site work in internet explorer?”

    Yes, it’ll be nice to have old sites in your portfolio look just as good as the day you made them and not have to constantly check if you site looks right; but really… unless IE8 takes over at an absurd pace, we’re still going to have to check sites in IE6 & IE7 until somewhere around 2010.

    This could be a large setback to progressive enhancement. But it’ll also be nice to make a site and just leave it alone.

    good read phil


  2. 2January 23rd, 2008 at 8:52 pm

    Phil Says:

    Hi Tim,

    You are right there, it is the legacy systems that require old version of IE to work that keep companies using older versions of IE so that system critical software doesn’t go down the tube. I know of one client who insists the site works in IE5.5 due to some users still having that browser.

    Yes, IE6 will be around a long time (although there is another plan to push IE7 through automatic download coming up), but we know how to deal with it for now and there will be a day when IE7 is the base.

    Look out for more on this coming up, there have been more advances today!


  3. Pingback by csskarma.com/blog » IE8 - Version Targeting
    January 24th, 2008 at 3:39 pm

  4. 3February 1st, 2008 at 12:49 pm

    Stevie D Says:

    “Before version targeting, you had to rely on an upgrade implementing standards correctly (something that should be reasonable, but rarely is), now developers will have to rely on browser manufacturers maintaining old rendering engines correctly.”

    The IE team will want as many people as possible to be using the latest version of IE. People will only do that if websites work properly. So as long as there is still a sizeable number of websites out there that need the old rendering engine, IE will continue to support it.

    “Browsers could become very bloated. Consider in 20 years time, where can reasonably expect to see IE15, by then there will be 9 different rendering engines that will be available to put into play at any time.”

    That won’t happen. If IE8 fixes everything, there will be little or no need to include separate rendering agents for IE9/10/11 etc. Yes, subsequent versions might include additional features, but not anything that would require a separate rendering engine.

    “Progressive enhancement will become vastly stunted. The idea of providing functionality that up to date browsers will be able to use, but locking the site to rendering by the browsers you tested in disables those bits of functionality that the browsers could potentially cope with (unless the developer returns to update the meta tag).”

    Two options. One is that when you add new features that require the latest version of IE, update your meta tag or http headers - the other is to set the meta tag to IE=”edge” in the first place, and then IE will behave just like any other browser and use the latest rendering engine. That seems like the most sensible way forward for competent designers.

    “Now, if the majority of sites out there are built like this, freezing time and rendering in 2007 with IE7 then no matter how much innovation goes on in standards or IE rendering, the most used rendering engine will still be the default IE7.”

    So what? The majority of sites don’t use CSS for layout. It’s still there for those of us that do want it! What matters to me is not what rendering engine other people are using on other websites, but what they are using to look at my website - I want to code a standards compliant site and know that people using IE, Firefox, Opera or anything else will see it as I want them to. We’ll have the option to use good practice - we can’t force other people to, no matter what we do.

    “What happens when you opt for a browser that a user doesn’t have? For example, say you opt for IE9 rendering and a user with IE8 visits. Do they render in IE8 or IE7 mode?”

    What happens now when someone tries to view an HTML5 page in IE6? Browsers will do the best they can - if a more recent engine is needed than is available, it will (I assume) use the closest matching engine, which will be the most recent. Yet another reason to use ‘edge’ rather than specific numbers.

    I was initially very sceptical about this proposal. But after looking at it more carefully, I’ve found my only argument against it is because it’s Microsoft, and I don’t like them and I look down on people who don’t code with web standards … none of which are very good arguments! There is, on the other hand, a lot going for this - it is, as far as I can see, the best way forward.


  5. 4February 4th, 2008 at 11:05 am

    Jonathan Nicol Says:

    “Browsers could become very bloated. Consider in 20 years time, where can reasonably expect to see IE15, by then there will be 9 different rendering engines that will be available to put into play at any time.”

    That occurred to me too, but here’s a little excerpt from a site point interview with Chris Wilson from the IE team:

    SP: Now, with this developer opt-in model that Internet Explorer and, if it goes into the HTML spec, all browsers will eventually adopt, are browsers over time going to have, you know, five, six, seven, ten, eighteen different rendering modes for each version of the spec that’s released over time, or will this tendency of the differences to tend towards zero over time mean that one day this can go away?

    Chris Wilson: I think that my personal hope, certainly, is that one day this gets to go away, that the differences between browser versions are not what we call internally ‘breaking changes.’

    I think the point you make about ‘freezing’ the web is an important one, and that is my biggest concern with version targeting as it is currently proposed.


  6. 5February 6th, 2008 at 9:50 pm

    Phil Says:

    Thanks for your comments, Stevie and Jonathan.

    You both make a point about later rendering engines not being so different that loads of new ones will be required. That is quite good and something I hadn’t considered, though it does rely on IE8 doing all the things right that it claims to (though with the Acid2 test, it is looking that way).

    I am in favour of the proposal in the end, it won’t affect me as I will be developing with, either the edge keyword or the HTML 5 DOCTYPE (as I mention in later posts on the topic) giving me the best of the browser’s ability whenever. If this helps other developers, those who own sites that will potentially break with the onset of a new browser and the users that have to go through the trauma of upgrading then it can’t be a bad thing and, since there are web developers who will further innovation online, at least parts of it won’t be frozen in 2007.

    I look forward to pushing the boundaries of IE8 and beyond.


  7. 6February 20th, 2008 at 12:35 am

    SneakyWho_am_i Says:

    Web standards. As already pointed out, when Safari/Opera/Firefox is upgraded we’re not these days running around pulling out our hair and trying to fix broken sites. This is because the standards don’t change with each browser version.

    If your page is going to look good in IE7 but not IE8, use conditional comments - that’s what they’re #^&% there for.
    Yes, the real concern is that whole “on the day, will it break my site?” thing… But that’s what public betas are for isn’t it? Does Microsoft do public betas?

    I used to spend 80% of my time writing a lot of unnecessary code to make IE imitate the acceptable level of standards compliance in other browsers such as Firefox (because we all know it’s easiest to code properly first and then go back and “fix” the things IE missed, right?)
    …
    Now I say, to Hell with it, I’ve stopped writing four times as much code for a bad browser. I know this is not an option for most - but I’m not most, my sites are mostly made for me alone, and when they’re not, it’s not an issue with my bosses ;)

    Every time you have to make a workaround for Firefox or Opera or something, allow yourself one workaround for IE if you really must.

    This meta tag is a very very bad idea. It will encourage people to stick with IE7, which is just plain stupid.

    Code according to the standards wherever you can. If someone visits a page and some particular thing isn’t implemented, screw them! “fixing” it for them is really “breaking” it much of the time. If their browser can’t meet ten year old standards, they shouldn’t be using it. Don’t try to accommodate them, make them get a proper browser.

    I won’t be adding any weird tags to my pages to make them work properly in IE 8. If you want to view my pages properly, you have to get a proper browser and that’s the bottom line.

    Microsoft is creating this tag to encourage people to not use standards-compliant code, and therefore on moral grounds it should never be used. It’s “innovations” like this that keep us mired in 1997.


  8. 7June 15th, 2010 at 4:42 am

    said suhil achmad Says:

    hai


Leave a Comment