bg-sharepoint.gif

Public SharePoint Sites and IE8 Compatibility

Removing the X-UA-Compatible tag from a SharePoint 2010 can have a lot of nuisances. This tag is there to force newer versions of IE to render the site in IE8 mode to avoid issues with new standards or updates mainly to the JS engine. But at the same time, it forces newer versions of Internet Explorer – that already support media queries and html5 elements, to render in IE8 mode and require the use of polyfills to implement the responsive design. This requires additional resources (polyfills) to be requested, downloaded, rendered, and executed – to implement something that is otherwise supported natively by the browser.

Don't Serve if it's Not Needed

I prefer to let IE9+ do their thing, since they already recognize our common pollyfills (media queries and html5 elements), and only implement the polyfills for when they are actually needed – visitors using IE8 , and when somebody is making changes to the site.

There are ways around this of course – one is to create two master pages and keep the X-UA-Compatible tag on the system master page. But this adds additional overhead to the project and forces you to maintain code changes to 2 master pages. Instead we can use a Security Trimmed Control to test whether there is even a need for this tag, else hiding it from the browser:

<head runat="server">
	<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
	<meta http-equiv="Expires" content="0" />
	<Sharepoint:SPSecurityTrimmedControl runat="server" Permissions="AddAndCustomizePages">
		<meta http-equiv="X-UA-Compatible" content="IE=8"/>
	</SharePoint:SPSecurityTrimmedControl>
	...

Note the Permissions attribute above. We use it here to check if the current user has the ability to customize pages, and if he or she does, the X-UA-Compatible tag is output to prevent the nuisances explained above. If the test comes back false, we know it’s a visitor who isn’t going to require the same level of compatibility with IE8. So we hide it in this case, and let the browser render in the most recent version.

So what are the advantages?

  1. Clients only need to maintain one master page instead of two.
  2. IE9+ downloads, renders, and executes two less polyfills.
  3. Native features aren't replaced by polyfills - that take longer to execute.
  4. IE8 specific CSS no longer needs to be rendered.
  5. IE8 specific JS is no longer downloaded.
  6. IE8 is still responsive.
  7. SharePoint Design Mode functionality is unscathed by the change.

More About the SPSecurityTrimmedControl

There are other attributes as well - PermissionsString and AuthenticationRestrictions. Between these two you have a wide range of control over when something should be displayed. These links will open in a new window:

  1. Reference for SPSecuirtyTrimmedControl
  2. Reference for AuthenticationRestrictions Property and Accepted Values
  3. Reference for PermissionsString Property and Accepted Values
;

Removing the X-UA-Compatible tag from a SharePoint 2010 can have a lot of nuisances. This tag is there to force newer versions of IE to render the site in IE8 mode to avoid issues with new standards or updates mainly to the JS engine. But at the same time, it forces newer versions of Internet Explorer – that already support media queries and html5 elements, to render in IE8 mode and require the use of polyfills to implement the responsive design. This requires additional resources (polyfills) to be requested, downloaded, rendered, and executed – to implement something that is otherwise supported natively by the browser.

Don't Serve if it's Not Needed

I prefer to let IE9+ do their thing, since they already recognize our common pollyfills (media queries and html5 elements), and only implement the polyfills for when they are actually needed – visitors using IE8 , and when somebody is making changes to the site.

There are ways around this of course – one is to create two master pages and keep the X-UA-Compatible tag on the system master page. But this adds additional overhead to the project and forces you to maintain code changes to 2 master pages. Instead we can use a Security Trimmed Control to test whether there is even a need for this tag, else hiding it from the browser:

<head runat="server">
	<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
	<meta http-equiv="Expires" content="0" />
	<Sharepoint:SPSecurityTrimmedControl runat="server" Permissions="AddAndCustomizePages">
		<meta http-equiv="X-UA-Compatible" content="IE=8"/>
	</SharePoint:SPSecurityTrimmedControl>
	...

Note the Permissions attribute above. We use it here to check if the current user has the ability to customize pages, and if he or she does, the X-UA-Compatible tag is output to prevent the nuisances explained above. If the test comes back false, we know it’s a visitor who isn’t going to require the same level of compatibility with IE8. So we hide it in this case, and let the browser render in the most recent version.

So what are the advantages?

  1. Clients only need to maintain one master page instead of two.
  2. IE9+ downloads, renders, and executes two less polyfills.
  3. Native features aren't replaced by polyfills - that take longer to execute.
  4. IE8 specific CSS no longer needs to be rendered.
  5. IE8 specific JS is no longer downloaded.
  6. IE8 is still responsive.
  7. SharePoint Design Mode functionality is unscathed by the change.

More About the SPSecurityTrimmedControl

There are other attributes as well - PermissionsString and AuthenticationRestrictions. Between these two you have a wide range of control over when something should be displayed. These links will open in a new window:

  1. Reference for SPSecuirtyTrimmedControl
  2. Reference for AuthenticationRestrictions Property and Accepted Values
  3. Reference for PermissionsString Property and Accepted Values
Return Home