We have this fantastic application of ours that is trying to render HTML 5 graphs using Google’s chart API. Before I describe the issue we faced with IE and its resolution, let me touch a few aspects of why we chose Google Charts as the library of choice.
Choosing a Charting Library
- Accept data as JSON objects or JSON arrays
- Had the chart types we needed to show (Bar, Line series, Area)
- Did not have a steep learning curve – one is always short of time!
- Was open source so that we could tweak it to suit our specific scenarios
- Had a decent set of defaults – i.e. did not required too much configuration to get up and running
As you look at the documentation for Google Charts, you’ll notice that it meets all of the above (and more). I’ll reserve the details of the fun we had while developing with this library for another post 🙂
Our friend IE! Now I know that it means well but good intentions alone are of no help! For some strange reason, when IE saw the HTML stream we threw at it for rendering, it decided to use “Quirks” mode for rendering along with the browser mode chosen as IE7 (even though we were using IE10). This was evident when we popped up IE’s developer tools by pressing F12 on the tab which had the website in question open:
Now, when Google chart API sees that it has to deal with an “old” version of IE, it tries to adapt by sending back VML tags in an iframe for rendering graphs. (details HERE). While it is all with good intentions, where this adaptation blows up is if someone clicks on the charts and drags – the charts scroll up in the iframe and may even disappear with no way to click and drag them back to where they were!
Easy: Tell all your users to quit using IE until it grows up! (wish this was an option :))
In the real world though, we needed to find a way to tell IE that it is dealing with grown ups and can just do what it is expected to – use standards mode and the best capabilities of the current version (IE10 in this case) to render our stuff! It turns out, there is an X-UA-Compatible header that is honored by IE when trying to choose a browser mode and document mode while rendering. This header may be added via a custom HTTP module (if you’re on ASP.NET) or via IIS Http headers settings. For details on how a custom Http module may do this, refer to my previous post where I show how one may tweak HTTP headers using the PreSendRequestHeaders event. For IIS settings, read on.
Assuming you are running a version of IIS 7 or above (you have Windows 7 or Windows Server 2008 or above) here’s what you’d do:
- Start -> Run, type in inetmgr and click OK
- You’ll see the IIS management console like so:
Click on the machine name node (Sudh in the above figure). In the right pane now, you’ll see several options depending upon your IIS and ASP.NET installation (i.e. what all you chose to install while setting up IIS and ASP.NET). The option of interest for us is under the IIS section in this pane and it should be called “HTTP Response Headers”:
Double click on the “HTTP Response Headers” icon and you should be taken to the configuration screen in the same right pane. Right click on the empty area or click “Add” from the Actions pane on extreme right to bring up the “Add Custom HTTP Response Header” dialog:
Add this in the name field: X-UA-Compatible
and this in the value: IE=edge
What this tells the browser is that it should use Document mode as standards and highest browser mode it is capable of. Details about the header and its values can be found on MSDN.
Once done, we revisited the website served by this IIS instance and popped up the dev tools in IE (F12) and as expected, Document mode showed standards Browser mode said “IE 10 Compatibility”. Good news was that the iframes were gone!
You can also add this or any other headers through the system.webserver config section in the applicationHost.config located by default at “%WinDir%\System32\Inetsrv\Config” like so:
<system.webServer> <httpProtocol> <customHeaders> <clear /> <add name="X-Powered-By" value="ASP.NET" /> </customHeaders> </httpProtocol> </system.webServer>
This can also be done programmatically as explained in the IIS developer center.
Turns out you can also include X-UA-Compatible as a meta tag in your master page/default.cshtml like so:
<meta http-equiv="X-UA-Compatible" content="IE=Edge" />
This technique is the easiest to implement especially on shared hosting where you may not be able to tweak IIS settings too easily. A great discussion on stackoverflow can be found here.
hope this helps,
Enabling Standards mode (Read for understanding how the box model deviates when document mode changes)
Stack Overflow discussion (Concludes that once document mode is standards, you should be good)