1 Posted by Harley on 23 January 2008 | Permalink

I work for the US fed gov and this particular shop is aimed at intranet IE. So I'll have the benefit of about six months to a year of watching the development community find the best solutions. That said, I'll probably end up NOT implementing the switch. Instead, I'll probably continue to use proven forward-compatibility techniques. Older sites may need tweaking because IE8's new fixes actually break old code, but that's been the nature of ALL development since the very beginning (platforms, APIs, everything changes constantly).

2 Posted by Sander Aarts on 23 January 2008 | Permalink

I guess it depends on a number of things:
* Will my employer tell me to implement it or not?
* Is version targeting a succes or not? Is fighting against it a lost battle?
* What is the total marketshare of IE8? If this 'fix' is not a succes then IE use will probably drop dramatically

BTW: is the market division give that of user agents or render engines being used? ;-)
If it's the render engines than the 'fix' seems to have been succesfull in your example web, otherwise it's not sure.

From where I stand now I hope most developers will ignore the feature, making it unsuccesful, as some have already mentioned. But I'm afraid this won't happen. Using the 'edge' option does not seem to be a wise choice though as Hixie stated (http://ln.hixie.ch/)

3 Posted by Rommert on 23 January 2008 | Permalink

1. Yes I would implement the switch in all new sites I create, because I want the websites to adhere to the current webstandards.

2. I probably will, because, again I want my websites to adhere to the current webstandards, not the ones that were defined at the time of creation of the website.

I can't take pride in my profession when I'm not developing according to standards and I certainly wouldn't be satisfied if any of my websites wouldn't adhere to the set standards. If it would take a few hours, so be it.

In the current debate, one of my favorite arguments against the use of version targeting is: "We're developing to standards, not browser versions." 'Nuf said.

4 Posted by Rimantas on 23 January 2008 | Permalink

Rommert, which standard exactly requires you to have that switch in place? None, afaik.
If you want your site to adhere to standards, just make it that way.
Somehow Gecko, Webkit based browsers and Opera will have no problem with it without any "switches".

5 Posted by Milo on 23 January 2008 | Permalink

1. Yes, because it means I no longer have to worry about the bugs in IE7 and can focus on IE8 which is (assumedly) more standards-compliant.

2. I will flip the switch and estimate the effort involved in un-doing the IE7-bug-workarounds and adding new IE8-bug-workarounds. If the improvement for IE8 users is worth the effort, I will go for it.

6 Posted by Rommert on 23 January 2008 | Permalink

@Rimantas that's a valid point. The switch isn't a set standard in the first place. But according to the IE development team the switch is needed to make the website _not_ render as IE7. Unless they change that default, the element is needed to make websites render with the latest rendering engine (with -hopefully- updated standards) in IE.

Of course I want my websites to be fully accessible and functional for the majority, so my only choice is to place the element. Unless -as previously said- the IE developers change the default setting if the element is left out.

7 Posted by Sander Aarts on 23 January 2008 | Permalink

@Milo
You still have to focus on bugs in IE7 (an probably even IE6 for some time) as not every IE user will, or can, update to IE8 immediately.

So it will be even more work, as you will have to support one extra IE version, unless IE8 renders exactly like Fx ans Sf of course.

8 Posted by Krijn Hoetmer on 23 January 2008 | Permalink

By the time IE8 reaches 80% and IE6 5% I think nobody uses the meta switch and the HTML5 doctype (or any other new doctype) is the standard way to trigger the 'new standards mode' in IE8.

If that happens my idea would be "to hell with bad browsers" and IE6 can get plain styleless semantic HTML to work with.

9 Posted by Krijn Hoetmer on 23 January 2008 | Permalink

Btw, perhaps IE6 and IE7 by that time reveal their hidden features, just as with <abbr> suddenly being supported by IE6 ;)

(http://intertwingly.net/blog/2008/01/22/Best-Standards-Support#c1201006277 and http://krijnhoetmer.nl/stuff/html/abbr-internet-explorer/ )

10 Posted by wortwart on 23 January 2008 | Permalink

Interesting question, but I don't think your IE market share is realistic. 15 months after IE7 it's still way behind IE6. Even today, IE6 is the most widespread browser. Sad.

11 Posted by Milo on 23 January 2008 | Permalink

@Sander Aarts
In my answer I made the assumption that I wouldn't care about the 20% of non-IE8 users.

Regardless, you make a valid point. One strong argument for this versioning is that MS can make IE[n] much less backwards-compatible with IE[n-1], since sites can simply ignore IE[n] completely until they're ready. The problem is that once they're ready, they still have to support both IE[n] and IE[n-1]. The compatibility problem still remains and will need to be worked around with hacks.

12 Posted by Nikola on 23 January 2008 | Permalink

With or without switch I'll continue to be an accessibility advocate. This means I'll be dealing with The switch. For the very same reason I'll be fixing old sites.

This might change with time if only "edge" is the default setting and not IE7.

Also with time and "edge" as a default setting if IE6 market share is drastically shrunk I may make some thoughts of dropping support for it and deliver only good ol' plain html, as Krijn suggests.

Sometimes I feel very tempted to drop completely support for all IE :)

13 Posted by Sander on 23 January 2008 | Permalink

Given the choice (that is, no absolutely essential feature would depend on it): no, I would not.
Although in that situation the version switch would be a decent short-term solution for me personally, it would be actively detrimental to the long-term prospects of an open and standards-based internet.
(That might sound too strong, but I can't seem to come to any other conclusion. I just wrote up the reasoning over at meyerweb: http://meyerweb.com/eric/thoughts/2008/01/23/version-two/#comment-304665 )

14 Posted by patrick h. lauke on 23 January 2008 | Permalink

1) CSS: Will IE8 still do conditional comments? If so, I'd grudgingly use those to get IE6 not to break monumentally, possibly feed a few little tweaks to IE7, and - depending on how critical my "favourite CSS feature" is (since my content will still be semantic and usable, even without some eye-candy if that's all that feature does), maybe even patch up IE8 and pray that IE9 better get it "really really right".

Javascript: do capability sniffing in first instance (as you should for do anyway), then browser sniffing for those browsers that lie about their capabilities ("yeah, sure i implement this method. oh no, wait, i don't *really*, but hey, we tried"). Or use a library that hides the horrible complexity behind an easy set of wrappers.

In both cases: constantly monitor my actual IE user distribution, and drop handholding patches when an old version drops below an acceptable threshold.

In short: do what I've always done anyway. But, as your scenario already has the meta as a given, I'm forced to implement the switch, aren't I? It doesn't look open to debate anymore anyway, it's a "you're either with us or against us"...

15 Posted by patrick h. lauke on 23 January 2008 | Permalink

2) Not quite sure I understand the question. By "old" sites, do you mean "coded in the past, but still live and active"? In that case, I'd do everything outlined 1) as part of my constant improvements/maintenance on the site.

If you mean "old" as in "done, dusted, still on web but effectively archived and only left there for historical reasons", then I wouldn't mess with them anymore. I assume that my new, cool, favourite feature (CSS or Javascript) wasn't around when I made them, so I wouldn't retrofit them to now have that cool feature anyway. If they're archived and I've not touched them even when IE7 came out, that means I'm happy with how they look right now in IE5/6/7.

16 Posted by patrick h. lauke on 23 January 2008 | Permalink

Now, it depends on how important their preservation is, and if I/my organisation have/has any policy on archiving sites. In some cases, I may already have to go through the archived site at some point to add a "this site is archived and only kept for historical reasons" banner at the top (maybe via some server-side script that preprocesses all pages under the domain, or ensuring that any access gets first routed to a disclaimer page warning that you're about to enter an archived site). So, if IE has its meta, I may have the chance to simply inject a meta declaring "this site should be frozen to IE7".
If the site is archived, but maintaing accurate presentation is not of high concern (as long as the content is accessible and well structured), then I may simply do nothing. Let a thousand websites break. It's old stuff. As long as it's still navigable and usable (though not pretty), fine.
And if all of a sudden somebody higher up decides that this low importance archived site needs to still work perfectly in the very latest version of IE they just installed, then its status moves from being archived to temporarily being back in development, and the meta is added.

17 Posted by patrick h. lauke on 23 January 2008 | Permalink

(If the meta didn't exist, then it would be a case of applying the steps in 1, possibly with a grumbling customer, but that's how the cookie crumbles in the organisation, unless there's some solid digital archiving policy in place)

p.s. the character limit here was quite an impediment to a thoroughly thought out answer...

18 Posted by patrick h. lauke on 23 January 2008 | Permalink

"And if all of a sudden somebody higher up decides that this low importance archived site needs to still work perfectly in the very latest version of IE they just installed, then its status moves from being archived to temporarily being back in development, and the meta is added."

or actually, the HTTP header for that site is modified.

do i personally think that simply dropping in a meta tag or doctoring HTTP headers is less work than reapplying the steps in 1? of course it's less work. of course it's easy. but it's not right. if a site is archived, that's that. if a site has a requirement to work in perpetuity, then a "life support" or maintenance provision needs to be in place.

19 Posted by patrick h. lauke on 23 January 2008 | Permalink

same as for digital archiving in general: you have to make sure your digital assets are still readable in the current technology...keeping around old technology that can still read it is one solution that gets out of hand very quickly...the sustainable solution is to continually look at the current state of technology and ensure the assets are in an up-to-date format. i recently did that with a whole bunch of old wordperfect documents that today's versions of word didn't like. managed to find a converter, then made two copies: one in word, one in openoffice format (as it's XML based, not encumbered with patents, and can hopefully be opened/converted easily in future). not to veer too far off topic, but you then also want to ensure that you always choose the format that introduces less compression/artifacts, i.e. a lossless format, whenever possible. but i'm thinking of photography and audio now...

20 Posted by Alex on 23 January 2008 | Permalink

I would use edge in both cases, because my sites are designed to work better as compatibility increases on all browsers, and there's no need to lock IE at 7.

As an aside, it's in MS's best interests for everyone to use edge, because then MS can improve their standards support as they see fit, and if it breaks a website that uses edge, they don't carry any of the blame. Also, if lots of sites use edge, maybe down the road they'll be able to drop support for older browser numbers, and shrink the size of their code.

21 Posted by Tino Zijdel on 23 January 2008 | Permalink

Right now I'm thinking of including IE=7;OtherUA=edge and put a button on all pages that says "Best viewed in real browsers, hacked for IE7" and then pray that IE will just go away...

Basically when MS is actually going to go through with this there is only a number of choices between bad options and I haven't decided yet which one is the least bad.

22 Posted by Sander Aarts on 23 January 2008 | Permalink

@Tino
Why not just ignore it then? Given what we now know, other browsers vendors are not going to implement this 'fix' and the default behaviour of IE8 will be as Jeremy Keith puts it:
"Unless you explicitly declare that you want IE8 to behave as IE8, it will behave as IE7." (http://adactio.com/journal/1402/)

If every developer would just ignore this switch. It will be as if IE8 was never released as it will render as if it's IE7. Time to development cross browser will not increase as you will still have to code for IE7 anyway after IE8 is released. And the differences between IE and other modern browsers will just increase, making IE look bad and others better.

I'd say "Let this switch hit MS like a boomerang instead of us developers".

23 Posted by Joost Diepenmaat on 24 January 2008 | Permalink

I'd put any site I would keep a watch on under the IE "edge" meta-tag, and fix the worst problems using conditional comments to include an IE-specific stylesheet, and hope like hell someone at MS would fix their browser to behave decently.

For sites that are really one-shot and forget, I might use the tag. But really, if you're developing sites for safari, firefox and IE (which is most of what I do - if it doesn't run on FF at least, it's broken), why the hell would you care about IE quirks?

24 Posted by adriand on 24 January 2008 | Permalink

I don’t think I will ever implement the switch. In that scenario with IE7 still making up 15%, I’m still going to have to code around its shortcomings. To cut down time in testing, I think I’d settle with letting IE8 act like IE7 instead of having to work around its shortcomings too.

That line of thinking potentially means I’m going to be locked into IE7 forever, which is a scary proposition. I’m hoping the way out of this madness will be with HTML 5 if its doctype triggers the switch in IE8 and IE6/7 are irrelevant by the time HTML 5 is usable.

That’s a lot of ifs.

25 Posted by Barney on 24 January 2008 | Permalink

I'm quite used to having no influence on IE development and not keeping a blog, so I feel a bit weird in concluding that I think the version switch is a very clean, unambiguous, and moreover useful tool; and that for once I don't have a massive essay to submit to the IE dev team on what they're doing wrong :)

PPK, thank you for keeping abreast of this, you're an invaluable resource for us front-enders who want to get news from the front without going to war :)

26 Posted by Frank Boës on 24 January 2008 | Permalink

On our sites we'd try to avoid switches wherever possible. But sometimes we use Conditional Comments. So in order to provide the best experience for our visitors, we would take any steps necessary to just do that.

But to be perfectly honest: At this time most of our sites work perfectly with any browsers (even though sometimes you have to think really hard to get the desired results). So I think most of us won't ever bother to use switches but for the most extreme situations.

27 Posted by Ali P on 24 January 2008 | Permalink

Here's my advice: use the new HTML5 doctype:

Because using the HTML5 doctypye will trigger IE8 mode WITHOUT using any fancy meta or http trigger.

-- “Steve”: Are there any doctypes that do not require this new meta tag to render with the IE8 rendering engine?

-- Chris Wilson: @Steve - sure. Any unknown (i.e. not widely deployed) DOCTYPE. HTML5, for example.

Just tried this on my valid XHTML4 page. Changed the doctype, had to remove one http-equiv meta, and the page
validated as HTML5. Plus it rendered as standards mode in all the browsers.

28 Posted by Suzy on 24 January 2008 | Permalink

1. Yes, in order to allow the progressive enhancements to start benefitting the wider populus, at last, and to allow standards to move forward

2. No, for 20%, and likely dwindling, probably not worth the effort.. look forward not back

80/20rule

29 Posted by Daniel on 24 January 2008 | Permalink

@Ali P, that suggests that once the HTML5 doctype is known, it will need a switch to get IE to use any later versions. So you won't get IE9 (or maybe IE10) mode.

30 Posted by Suzy on 24 January 2008 | Permalink

sorry misunderstood question 2. but Probably still a no, unless the site overhaul was justified for some other reason too or I was getting paid for it ;)

The point is, I presume, we have a choice either way with this solution.

I think the proposed solution is the best compromise there is and I agree with the default behaviour. It would be an ideal to have it the other way but not practical. I'm not just thinking in terms of broken 'WYSWYIG' sites.

consider the actual render engine itself.. IE is not like Firefox or Opera were when they were teething, they cannot rely on users updating versions regularly just to get the latest bug fixes or take advantage of the latest CSS/JS etc.. that's for us enthusiasts and developers.

There is no way, even though the standards advocate in me would like there to be, that any solution will be anything other that a compromise. IE's a big tanker that takes time to turn, it's started turning but obviously needs a hand.

I'm for it as a means to an end - The Goal being Full Web Standards Compliance. So somebody better shout loud if they deviate from anything other that the Web Standards

31 Posted by Tanny O'Haley on 24 January 2008 | Permalink

1. I'm going to have to see what it takes to make the site work with IE8, IE7, IE6. I may just take the lazy what out and code for IE7, IE6 and compliant browsers. I really dislike polluting my HTML. I don't even like conditional comments, though I use them, I don't want to.

2. Unless the site requires an upgrade, no.

I don't think that this switch is a good idea. IE7 "broke the web" and the world didn't collapse. If IE8 breaks the web, programmers will fix their web sites and carry on, IE8 will still support conditional comments, right?

32 Posted by Ali P on 24 January 2008 | Permalink

Re. the HTML5 doctype (which will almost certainly be "DOCTYPE html") - of course no-one knows how IE9 and 10 will behave, but I'd be very surprised if the HTML5 doctype "froze" IE9 and 10 etc. at IE8.

OTOH that's exactly what's happened with the HTML4 doctype...

Anyway, shrinking your doctype seems to me to be a neat solution that obviates worrying about metas or headers. If you're already doing valid HTML4 it's a very painless switch.

33 Posted by David Clarke on 24 January 2008 | Permalink

I have a friend who cobbled together a site using some version of Dreamweaver. It was a dreadful mess and in addition to being emphatically not standards-based, it also contained all manner of cruft and voodoo intended to push it up the search engine rankings. So from what I've read to date, this is the guy that Microsoft is trying to protect with this meta tag. What I see occurring is my friend getting the inside scoop that adding this one-line meta tag to his pages will make his site look cool in the latest version of IE.

As a web developer I intend to avoid using this tag because it will make the cost for me to support new versions of IE higher, hell I'll just stick with the default rendering that MS says isn't ever going to change. The likes of my amateur friend however, with the assistance of a tool (that will say "do you want your site to render in IE8/9/10 etc" to which the correct response is "hell yes") are going to be all over this meta tag. The outcome from this will not be the one Microsoft anticipates.

34 Posted by pixelpusher on 24 January 2008 | Permalink

Yes, I'd implement the switch.

Best to code to standards and let Microsoft bear the onus of backwards-compatibility for their non-compliant browsers.

35 Posted by BARTdG on 25 January 2008 | Permalink

It depends on the level of standards compliance of IE8. If it's still far less compliant than the other browsers (which PPK's quiz suggests), I won't bother. By not using the switch, I'll have IE8 render my site in IE7-mode. This allows me to develop for compliant browsers, then hack to get it to work in IE7.

I am definitely NOT going to do any extra stuff for yet another browser. Period.

The longer I consider it, the more I think this version switch is actually a good idea. It makes sure Microsofts problems are not going to be my problems or the problems of my users. If IE8 is standards compliant, IE=edge will make it use the hackless "other browsers"-version of my site. If it's not, it will use its IE7-mode.

In fact, this may lead to the situation in which Microsoft either has to come up with a standards compliant IE9 very quickly, or accept that developers are going to ignore newer versions at all.

36 Posted by Chris on 30 January 2008 | Permalink

I for one will probably ignore the switch. Since Microsoft won't force users to update their browser, we will be forced to cater to the IE7 (and IE6) users for many more years. Adding support for a new IE, that will undoubtably contain many new bugs and quirks, will only add more complexity to allready complex cross browser code.

If Microsoft decides to implement this switch, IE will forever be IE7 as far as I am concerned...

37 Posted by Stuart Steel on 31 January 2008 | Permalink

1/. Yes. We would start to use the feature - we would try to fit it into our systems to reduce workload/stress. With a majority of the web using IE8 I think it is better to be flexible than be dogmatic and let our product, and our users suffer.

2/. Probably not. The cost of implementation would be too high. Although we may raise it with customers when reviewing / updating their site. If a site is x years old at a certain point it has to just accept its technological / chronological limitations.