IE 8 Compatibility Mode and SharePoint

Recently, the Internet Explorer team released IE 8 beta 2.  It’s a monumental leap forward for not only web designers but also the Internet.  However, it is not without controversy, but first it needs a little background.

A Little Background

Internet Explorer has for a long time been the bane of web developers.  Every since they won the browser war over Netscape (nearing a decade ago now) with what were judged unethical and illegal means which led to a monopoly investigation.  That was settled and Microsoft allowed to continue.  Since then web designers have had to hack, glue, and curse IE due to its large lead on browser usage.

Internet Explorer 6 released in 2001 has been the infamous browser that just will not go away.  Grassroots movement such as Save the Developers have said “enough is enough” and want to see IE 6 erased from the technology landscape.  But even in 2008, seven years later, they still average around 25% of all browsers in usage today.  IE 7 was released and was a huge step forward in standards conformance, security, and compatibility.  It gave both designers and end users hope for the future of IE.

The Controversy Today

Recently when IE 8 was announced it boasted an impressive conformance to several web standards including CSS 2.1, DOM improvements, and even parts of HTML 5.  It also boasted that it passed the Acid 2 test which tested conformance to the CSS standard published by the W3C.  We were all excited until they made their second announcement.

The IE team, under intense political pressure, offered three modes of browsing in terms of web standards support.  It offered the following.

1. Quirks Mode — long standing behavior reminiscent of IE 6, and it was used when no DOCTYPE was specified.
2. IE 7 Mode — With a DOCTYPE it rendered according to IE 7’s standards support.
3. Standards Mode — with the inclusion of a META tag IE 8 would render in the strictest manner possible according to the DOCTYPE.

The community revolted in a way I’ve never seen before, and the IE team decided to have the standards mode be initiated by default with a DOCTYPE, and if the designer wanted IE 7 mode he had to use a META tag.  A major victory was won, and designers everywhere rejoiced and anticipated IE 8.

Compatibility Mode for Intranets

With the release of beta 2 of IE 8 they introduced compatibility mode with some interesting defaults.  They announced that IE 8 would, by default with a DOCTYPE, render all Internet (public) pages in the strictest manner possible per the aforementioned victory.  However, by default all intranet sites (with a URL such as http://moss) would render in compatibility mode.

It’s interesting that they mention SharePoint specifically in the blog post, because I’m sure this move was politically based as I have yet to see a web-based MS application with the political clout that SharePoint has in the enterprise.  This setting is configurable by Group Policy, but it is doubtful that many enterprises will take this as an action item.

Thankfully, the IE team has two META tags that can override all these compatibility view settings.  One emulates IE 7 rendering engine used most prominently for backwards public-facing sites, but there is also an emulate IE 8 META tag to force sites, even specified to render in compatibility mode.

So, Why Should I Care?

I believe there are two major ramifications of this.  The first effects the end user, and the second effects intranet developers.  The only people I can really see caring about this on the development side are those branding SharePoint.  Let’s talk about each.

First of all, the end user doesn’t have the final say whether or not a site is rendered in standards mode or not.  Now, probably most if not all end users could care less, but the addition of a button in the address bar that appears “broken” designates pages that may not be broken but actually rendering perfectly in standards mode but the end user could be drawn to change the behavior because it appears the page is broken.  So with a misleading option in the UI and overriding behavior given to developers over users is a concern.

Secondly, the concern is for those branding SharePoint or other intranet sites.  What scares me is that this decision was pushed by, for instance, the SharePoint team for its product.  I fear that this is indicative of how the next version of SharePoint will be crafted—around compatibility mode and not standards mode.  Any developer will tell you how horrendous the markup and CSS is for SharePoint out-of-the-box.  I was eagerly anticipating the SharePoint team learning from their mistakes in crafting the core styles and master pages by going to a much stricter standards-based site which makes it much easier to brand, far more accessible, and even faster loading.

What Should MS Do?

My hope is that the IE team will respond to such a critique as this as they did their first decision.  Here are some steps I’d encourage the team to take:

1. Render all sites, intra or internet sites in standards mode unless a META tag is present or lack of DOCTYPE.
2. The end user has control over whether or not the site truly displays one way or another.
3. Remove that confusing button in the IE UI which is a poor UX decision.

Will they respond as they did before?  I don’t know, but I can only hope they’ll see the negative ramifications of this for end users and developers alike.