In the SharePoint branding & development communities, there has recently been a lot of buzz around the use of HTML5 features in SharePoint.
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 bind.pt 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:
- On-demand (a.k.a. reliable) IE9 rendering for SharePoint 2010 Master Pages.
- Code sample: Modify Schaeffer’s v5.master to be IE compatible