Well, the Windows 8 Consumer Preview just released, so it’s time to start fielding questions about Windows 8 app compat. Though, honestly, the largest number of questions I’ve received so far have been around Internet Explorer 10.
Now, I work in the Enterprise space, so my guidance here might be slightly different from the advice which we would give to somebody who hosts a public facing website. A public-facing website typically has a team of folks responsible for updating it all the time. They have to concern themselves with potentially any browser, and any version thereof. When something new comes out, you hopefully allocate time to have a look and make sure everything is working OK, to ensure that your users consistently have a good experience. But that is qualitatively different from the way things work in the enterprise, where you have some say in the browser used (and usually have the ability to enforce that), and where you typically don’t have resources allocated to actively manage every web application running the business because you can’t afford to. There are usually far more sites than developers.
As a result, enterprise customers are looking to build more durable web applications.
Now, durable applications are often implemented by freezing the platform – and it’s that platform freeze that is making some enterprise customers pretty sad right now. Those who feel trapped with IE6 are feeling the candle burning on both ends, as more and more web applications and web sites no longer support that platform. It’s becoming more and more clear that freezing the platform may not be the best way to implement durable solutions. So, as my customers start to look at updating to Internet Explorer 8 or Internet Explorer 9, they are concerned about once again making a durability bet based on freezing the platform. They don’t want to end up getting stuck on Internet Explorer 8 when Internet Explorer 9 is already out, and Internet Explorer 10 is on the horizon. So, how can they implement durability on the Internet Explorer platform without demanding a platform freeze?
This is precisely what the IE Compatibility Infrastructure was designed to do. On some level, Internet Explorer is a container which hosts several different browsers. Making sure you are intentionally using the right one is the key to more durable solutions.
Here are the different rendering engines we have included in the past several releases of Internet Explorer:
| Engine | IE6 | IE7 | IE8 | IE9 | IE10 |
| IE5 Quirks | x | x | x | x | x |
| Interop Quirks | x | ||||
| IE6 | x | ||||
| IE7 | x | x | x | x | |
| IE8 | x | x | x | ||
| IE9 | x | x | |||
| IE10 | x |
You can see that we haven’t discarded one in a while. In fact, the only one we have discarded is the IE6 standards engine, which we updated to the IE7 standards engine. This actually wasn’t as disruptive as many people worry it will be when they are still on IE6 – the number of breaking changes was manageable. The bigger problem is that many applications which ran in IE5 Quirks on IE6 were promoted to standards when we fixed a bug in IE that caused us to ingore doctypes if they weren’t the first line of code in the markup (I discussed this in my article in the August 2011 issue of TechNet Magazine .)
Add Compatibility Metadata Using X-UA-Compatible
As you can see from the above table – if you get your web application working in any of the rendering engines used by IE7 or later, that engine will continue to exist on all of the browsers we have released subsequent to that. That, indeed, helps you have a more durable solution! Of course, it’s not perfect – when we implement a new security feature in the browser, we implement that feature across all of the rendering engines. (Otherwise, the bad guys would just ask for the insecure one.) However, it is remarkably effective.
How effective?
The number of bugs I have investigated for apps which worked on IE8, but which didn’t work on IE9 and could not be fixed using one of the compatibility engines, worldwide, since we shipped IE9, is 4. Not 4% – the integer 4. Like I said, it is remarkably effective.
That being said, one thing I do find strange is when an application requests EmulateIE7, or EmulateIE8. These emulate modes are themselves decisions. So, instead of being specific about what you want, you’re asking for one of two things and then determining which of those two things by looking elsewhere in the code for a DOCTYPE (and then attempting to understand whether that DOCTYPE will give you standards or quirks depending on its contents – another sometimes confusing task). Rather than do that, I think it makes significantly more sense to directly specify what you want, rather than giving a response that is itself a question. If you want IE7 standards, then use IE=7, rather than IE=EmulateIE7. (Note that this doesn’t mean you shouldn’t use a DOCTYPE – you should.)
Order of Precedence for Rendering Engines
So, when do you add this metadata, and how? My personal recommendation is to add it all of the time – when will it hurt you to have included data that informs future developers or browsers the design assumptions and platform on which the application was tested? I can’t think of a scenario where that is bad at all! So, the general advice I give is to add it any time you can afford to touch that application. Of course, if you can’t touch it, then you have to rely on the heuristics, which you can define through group policy. The unfortunate thing is that these heuristics are less powerful than the metadata would be.
The order in which we honor requests is:
A meta tag overrules the header, and the header overrules the policy. So, I only use the defaults if the developer or server admin specified nothing. If the server admin specifies something via the header, any individual page can opt into something different (older or newer) by including a meta tag. It all works out quite sensibly, as you can assert control at any level of granularity that you want.
Of course, I have had people base their approach to compatibility metadata on the assumption that the group policies have the highest precedence, which is often because they have done some experimentation and believe that to be the case. When that happens, it’s good to figure out why.
When X-UA-Compatible Doesn’t Work
If setting up X-UA-Compatible isn’t working, it’s helpful to figure out why, because having the browser behave in line with the precedence order I just defined is really important for establishing a good baseline policy.
There are two scenarios where I have seen this metadata be ignored, and it’s helpful to be aware of both:
Syntax Errors: There have been some samples published, which then get contributed to the world of search engine cut and paste, which had syntax errors.
<!-- This is a syntax error –->
<meta http-equiv="X-UA-Compatible" content="IE=IE8" >
<!-- This is the correct syntax –->
<meta http-equiv="X-UA-Compatible" content="IE=8" >
Placing the Meta Tag Too Late: If the meta tag appears after we have had to determine the rendering engine, then you are too late. You have to include that metadata before running scripts or rendering HTML. The mode can be switched only before you’ve done any work which uses a rendering and scripting engine, otherwise we decide based on the header or the group policy.
<!-- This is too late –->
<script type="text/javascript" src="script.js">
<meta http-equiv="X-UA-Compatible" content="IE=8" >
<!-- This is good –->
<meta http-equiv="X-UA-Compatible" content="IE=8" >
<script type="text/javascript" src="script.js">
So, if you think that this metadata doesn’t work, or doesn’t work in the order of precedence defined above, then I would have a look and see if either of these problems might be distorting your opinion. When I work with customers who believe otherwise, I normally find this as the cause, and once identified we can carry on to build a more sensible strategy around helping make enterprise web applications more durable leveraging metadata and the compatibility infrastructure of Internet Explorer.
Monitoring and updating standards
When thinking about durability, it’s also important to ensure that the durable solution you are building is also one that is gradually modernizing. Just because you can continue to build new web applications based on an implementation of web standards that is now 12 years old doesn’t mean you should. In fact, you really shouldn’t. You lose out on all of the great new capabilities of the web, things such as HTML5 and faster script performance, while you are living in compatibility modes.
In addition to adding metadata which describes where the application runs today, I think the first step to really getting the most out of your browser is to start tracking which rendering engine you are using for each site, and start to look at some statistics. If you’re like most organizations, you’ll probably find that you have a surprisingly large number of IE5 Quirks mode web sites. You’ll also probably find that much of the rest of what you have relies on IE7’s implementation of web standards.
With this knowledge in hand, you can then build a strategy around how you intend to update your usage of standards over time, leveraging the natural development patterns for each product and enforcing certain levels of standards for new products coming in. For example, you may discover your current state and set in place a 5 year plan that looks like this:
I don’t recommend disabling legacy compatibility all at once. First of all, it costs more – you’ll be investing money in a large number of web applications where there is no ROI, and the organizations and teams who attempt this seldom actually have the budget to execute against that goal. (None that I have worked with so far have.) The approach of enforcing your standards at the entry point, when new applications or significant updates are deployed, is much more effective long-term than boiling the ocean. Of course, this requires that you have the ability to implement a quality standard for new software being deployed. I think you should.