Be wary of HTML5 “solutions” with SharePoint 2010

In the SharePoint branding & development communities, there has recently been a lot of buzz around the use of HTML5 features in SharePoint. Solutions like Kyle Schaeffer’s “v5.master“, or Bind templates are being deployed, and this has me a little concerned.

In my testing with IE9, I have found that various pieces of functionality do not work as expected with these solutions. The reason for this is as follows: SharePoint 2010’s IE9 support was tested and developed for IE9 running in IE8 compatibility mode, but these solutions typically disable the compatibility mode, breaking basic SharePoint functionality in the process.

Specifically, the tag…

<meta http-equiv="X-UA-Compatible" content="IE=8"/>

… has been either removed, or changed to one of these alternatives…

<meta http-equiv="X-UA-Compatible" content="IE=9"/>
<meta http-equiv="X-UA-Compatible" content="IE=edge"/>

It would be great if this worked, but the unfortunate truth is that there are various pieces of critical SharePoint functionality which simply don’t work if this is changed.

Solutions which change this tag do not stand up to basic functional testing. Here are just a couple of irresolvable breakages that occur when using IE9 in non-compatibility modes:

  • Resolving people in the people picker doesn’t work
  • “Non-enhanced” rich text column in edit mode
  • The above issues can cause “OK” buttons in form dialog boxes to break (e.g. calendar dialog boxes)

(If you’ve found other functionality which is broken, please report it in the comments.)

I cannot think of an intranet deployment I’ve worked on where this would not be a “breaking” issue. This is stuff that’s in the ‘team site’ template (i.e. the calendar). The people picker and rich text fields are key functionality, used by various core templates inside SharePoint.

It’s all too easy to forget that we’re working on expensive, comprehensive enterprise software which is expected to perform reliability and quickly in a business context. I would encourage branders to become more familiar with the ways in which SharePoint is used and configured, and to test those scenarios thoroughly when attempting to radically change the appearance of SharePoint – even if that testing isn’t automated or easy.

It’s possible that modifying the underlying browser.compat in SharePoint may allow the use of HTML5 features – but there are no published sources that suggest this might work, and this would create an unsupported configuration.

In the mean time: use shims, and test responsibly.

Update: I contacted regarding this issue: they have told me that they are aware of the issue, and have added an item on their knowledge-base which covers it. I have confirmed that this is still the case with their latest theme (Flexo) as of May 23, 2012.

My Related Gists: 

Useful Shims


  1. HTML5 and responsive layouts are fine for publication layers where sites have to work in all browsers, not just IE9…
    I would say be weary of implementing any third party solution without testing it thoroughly…

  2. As with everything, it depends. If you’re building an Internet site on SharePoint, for instance, HTML5 may be both desirable and preferable, assuming you understand your user base and consider decent fallback and shimming strategies.

    Using some HTML5 capabilities with some parts of your user population even on an Intranet may make sense. It may even make sense to have a fully HTML5-enabled home page. All of this is possible if you do the work.

    Those of us who have written about getting HTML5 capabilities working with SharePoint – myself included, as I have a series on – are simply trying to answer the many questions people have about how to do it. In my writing I’ve tried to be very clear what the challenges are and what to think about before you get started.


    • Thanks for the comments Marc. FYI I have added a link to one of my gists, showing how a ContentPlaceHolder might be used to selectively enable IE9 rendering mode on certain pages. I’d suggest this method might be a more reliable way of using HTML5 features in IE9 on custom ASPX pages and publishing page layouts, while still providing good ol’ reliable IE8 rendering on ‘boring’ pages.

  3. Have you tested with an SP1 and December 2011 CU farm? Based on my tests at least the people picker issue is resolved. SP1 is supposed to support IE9 in full compatibility mode too.

  4. Hi,

    We are having a .NET application being migrated to SharePoint 2010. The UI concept is being created in HTML5 supported by CSS and JQuery.

    We want to integrate this with SharePoint 2010 creating SharePoint Master Pages, Page Templates, Pages and webparts for functional components.

    An alternative to this is being suggested where we use ASPX pages and add the entire the HTML5 code created in the concept under this page and do not implement any webparts.

    I want to understand from experts in this forum what is the recommended approach and how can we arrive at a solution for such an implementation?

  5. If you use both the sandbox and farm deployment packages of this solution, it overcomes the issues identified above.

  6. Late to the party – but one thing I do on SP master pages is implement a SP Security Trimmed Control, and test whether a user is authenticated and has permissions to edit the site. If it’s true, I stick in the X-UA-Compatible tag, if not – then we benefit from not having to serve polyfills to support responsive designs in IE9 and 10.

Leave a Reply

Your email address will not be published.


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

© 2015 get-spblog

Theme by Anders NorenUp ↑