Always check your stats.

Peter Paul-Koch, FrontEnd Day Workshop

Sometimes I feel like this when looking at Google Analytics...

There is just so. much. data. I'll be honest when I say that I don't enjoy the time I spend staring at area charts and fighting with the Google Analytics DatePicker. We do of course watch our site traffic, and in terms of Developer Relations, we do it to help us determine what content is valuable vs that which generates low interest.

While going through the numbers for the previous quarter, I got distracted looking at browser traffic on the main home page. The stats I saw don't generally jive with what we see from the larger global number aggregators. PPK says that your stats are the only ones that matter, so here we go.

Before we get started, I should note that this is desktop browser traffic only. Mobile is another story entirely that I can't possibly fit in here.

Overall Stats

The big watchers in the browser statistics space tell us that Chrome is the dominant browser, but not by much. It only recently superseded IE as the number one. For traffic to Kendo UI, Chrome is not only the dominant browser, it's WAY ahead of the others.

If you stop and think about that, it makes sense. We are developers. Chrome and FireFox are typically the "developer's browser", even if we aren't building sites or apps targeted for that browser. It's also not going to be surprising that IE is the third most popular browser.

So we know which browsers are the most popular, and it pretty much jives with what you would expect. The next step is to drill into the exact versions.


Of course, Chrome's infinite versioning makes it a bit unique. Most developers can tell you what version of IE they use, but few can rattle off their Chrome major version. As I'm writing this, I myself cannot recall what the current major version is.

After looking at the stats, over 80% of people are on the previous two Chrome versions (28.0.1500.72 and 28.0.1500.95). I've also made a mental note that the current major version is 28. I'm sure it will be in the 30's by later this afternoon.

The other roughly 20% of Chrome use is pretty evenly spread out among other random versions in small numbers after a jump down from major version 28.


As for FireFox, things are a bit more interesting. As of version 4, FireFox implemented the same sort of "infinite versioning" that Chrome introduced. You can see in the FireFox version breakdown that aside from folks that are holding on to version 3.6.8, FireFox is relatively up to date.


The most interesting insight was what I found when I drilled into the IE statistics. IE has had a rough road with upgrades. Version 7 and 8 are not stellar, and when I talk to people, they are typically supporting one of those two versions at their place of employment. I would have assumed that those two versions still comprise the majority share.

To my very pleasant surprise, this was not the case at all. Check it out:

It's perfectly in order, right down the line. Exactly like you would expect it to be in a perfect world. Well, in a perfect world it would all be version 10, but let's not gain false hope. However, most people are using IE 10, which is a stellar browser. Next in line is version 9, which lacks in some places, but all in all will work just fine for modern web development.

Legacy IE

Unfortunately, we also have "legacy IE", or any version that is 8 or below. Wah wah. These browsers are considered inadequate for modern web development, and generally need very special considerations to make sure that sites and apps continue to function the same way they would in IE 10 or Chrome. For instance, IE 8 and below have no support for CSS 3 Media Queries.

The Thickening Of The Plot

The problem with IE versions 7 and 8 is further exacerbated by a few factors:

No Side-By-Side Installs

Like other browsers, you can't install IE 9 on the same machine running IE 8. It's not a supported configuration. This means that if you are required to run IE 8 on your main machine, you won't be running any other IE versions. You can run another browser altogether like FireFox of course, but many enterprises keep tight control over which browsers users are allowed to install for work use. This helps companies control their support burden by only having to ensure support for internal applications on 1 browser. The last thing you need is a bunch of users calling in because SharePoint doesn't work on Chrome. Nobody knows better than us as web developers how much of a pain it can be to support multiple browsers.

Compatibility Mode

This one is really sticky. It's so sticky in fact, that it's going to be the subject of the rest of this blog post.

First A Note On Quirks Mode vs Standards Mode

Before we talk about how Microsoft handles compatibility with legacy versions of it's own browsers, we need to take a look at how the web at large handles legacy browser issues by way of something called "quirks mode".

Quirks Mode

In the beginning, there was Netscape and IE. Standards were slowly emerging, but each browser was doing things their own way in the absence of strong standards bodies. Once the standards bodies began establishing guidelines for the web, browsers still had to be able to live in both worlds. A world where sites were written to work in Netscape or IE, and a brave new world where sites would work everywhere. Handling pre-standards sites was known as "Quirks Mode". Expecting a browser to play by the standards was known as "Standards Mode".

The web developer essentially had a way to tell the browser to use standards, or ignore them and use the browsers individual quirks. This was done with the doctype.


Doctypes have a long history of being hideous. Especially some of the XHTML Doctypes. Fortunately, we have a new "standards" doctype that is nice and simple. You should commit it to memory. It's not even case sensitive, so you have no more excuses. This one you should know by heart.

Standards Mode Doctype

<!DOCTYPE html>

This tells the browser to display your site with the latest standards (or at least the standards that it is aware of). If you put ANYTHING else in that doctype, you run the risk of triggering quirks mode. If you are not intentionally turning on quirks mode, all bets are off as to how your site may render.

You can read more about Quirks Mode and Standards Mode over on MDN.

This whole web thing started with standards fragmentation. It only gets worse from here.

Post IE 6 Fallout

IE 6 was a groundbreaking browser, but it was also a standards breaking browser. IE 6 wasn't really focused on standards as much as it was on being intuitive and easy for the developer to use. Unfortunately, in the long run this proved to be extremely problematic as FireFox pushed us into a multi-browser world. This new world was all about standards, and even when not in quirks mode, IE 6 had some major layout issues (specifically with it's box model) when it came to standards. Microsoft began to reverse this decision with IE 7. However, they did so relatively slowly. Knowing that not everyone was going to run and update to a newer browser version, they introduced something called "Compatibility Mode" when they launched IE 8.

As mentioned by Eric below, compatibility mode was not offered in IE 7, which really slowed down it's adoption.  Microsoft wants people to move to a better browser, but they can't very well just yank the rug out.  Compatibility Mode was introduced with IE 8 to help provide a path for users to upgrade their browser while ensuring that all of their sites continue to function.

Compatibility Mode

Compatibility Mode is that little icon up the URL bar that looks like a broken page. The idea was that if a user visited a site that looked broken or jumbled up, they could click the icon and even though they had IE 8, it would use the IE 7 rendering mode which would - in theory - fix the problem. This was an effective approach, and it followed subsequent versions of IE so that you could always fall back to the previous versions rendering mode if you needed to.

On the surface, this seems like a harmless and effective way to give users the best of both worlds. There were a few nasty side effects though.

Site Lists

As users visited sites and clicked on the icon, IE remembers this choice and ALWAYS displays that site in compatibility mode from then on out. Even if you update the site. The user would have to manually turn it off in order to revert the browser to it's highest available rendering mode. Or they could just go into internet options and clear the list. A lot of users know how to click an icon, but most will forget that they ever did it. Very few are brave enough to traipse through Internet Explorer settings. That's what the help desk is for.

Windows Update

For IE 8, Microsoft maintains a list of sites that it has identified to be in need of compatibility mode. This means that if your browser version lines up with the ones Microsoft wants compatibility mode on with, you get served up an IE 7 experience. This is only true if Windows Update is turned on.

Intranet Zones

One of the more shocking revelations was that if your site is picked up in the intranet zone, it will automatically fall back to compatibility mode without the user ever clicking on the icon. That means all your internal intranet apps get displayed in legacy rendering without you or your user ever making the decision to do that.

Taming Compatibility Mode

Fortunately, Microsoft also provided you - the intrepid web developer - with a way of sending a message to IE to tell it that you want to use a specific rendering mode. These strategies allow you to override any setting that is there currently, including the "intranet zone" issue. There are two ways to do this.

Meta Tags

IE determines compatibility mode based on two factors as of IE 8:

  1. The value of the !DOCTYPE switch (determines "quirks" mode)
  2. The value of "Compatibility Mode"

Possibly the easiest way to tell compatibility mode to pound sand is to place a special meta tag in the head of your page which specifies which version of IE to use. This is the strategy that HTML5 Boilerplate uses. The following example tells IE to always use the latest and greatest rendering mode.

Meta Tag To Turn Off Compatibility Mode

<meta http-equiv=“X-UA-Compatible” content=“IE=edge” />

The following table displays all the options.

Common Name

Compatibility Mode Value




IE 5.5 (Quirks) rendering mode

IE 7 Standards*


IE 7 standards rendering mode

IE 7 Emulation


IE 7 standards or Quirks rendering, depending on DOCTYPE

IE 8 Standards*


IE 8 standards rendering mode

IE 8 Emulation


IE 8 standards or Quirks rendering, depending on DOCTYPE

Latest Mode*


Always use the latest standards rendering mode

Source: Understanding Compatibility Modes In IE 8 - MSDN Blogs

You can target specific versions of IE, but most likely you are just going to be trying to make sure compatibility mode never gets triggered. You can also do crazy things like setting the rendering mode to IE 7 and putting the browser into quirks mode. Hopefully you will not ever have to see that day.

If you have a lot of existing sites without this meta tag, you may not want to go and make that change in every site and republish your code. In that case, you have two choices for controlling Compatibility Mode at a higher and more global level.


You can put this file in your site, at the root of the domain, and IE will check for it. This file can specify which rendering mode you want to use. Unfortunately, IE only checks this file every 30 days. This means that any updates you make to that file on your server will not be immediately applied to the browser.

That was underwhelming; I know. Don't worry, I've saved the best for last.

HTTP Headers

You can set an HTTP Header that will do the same as the meta tag does. This can be done at a server level, and therefore can be an immediate fix for all of your sites.

HTTP Header To Control Compatibility Mode

X-UA-Compatible: IE=edge

If you happen to have both a meta tag and an HTTP Header, the HTTP Header will win.

What To Expect When You Are Expecting

In the process of trying to make IE behave well as it progressed forward towards better standards compliance, Microsoft somewhat complicated things for us as developers. Apparently the web just isn't complicated enough as it is. If this article proves nothing else, it's that this stuff is seriously complex.

Knowing what to expect in different configurations can really save your sanity. Frameworks like Kendo UI that are compatible all the way back to IE 7 will help a lot too. Let's face it: nobody wants to go down this road alone. We're here for you. Let's tame IE together.

Burke Holland is the Director of Developer Relations at Telerik
About the Author

Burke Holland

Burke Holland is a web developer living in Nashville, TN and was the Director of Developer Relations at Progress. He enjoys working with and meeting developers who are building mobile apps with jQuery / HTML5 and loves to hack on social API's. Burke worked for Progress as a Developer Advocate focusing on Kendo UI.

Related Posts


Comments are disabled in preview mode.