SP2010 and IE9 Compatibility mode

Feb 21, 2013 at 1:10 PM
Hello,

I have only recently begun looking at sharepoint branding for our team's instance of sharepoint. One of the big issues that I am trying to figure out is how changing the document mode of SP 2010 pages from IE8 to IE9 affects sharepoint. I've been doing some research online and found some issues people listed (like system pages not loading correctly inside of a dialog box) but most of those issues were posted early on while IE9 was still in beta. Wanted to check and see if you have seen any issues with default functionality with bootstrap changing the doc type to IE9.
Coordinator
Feb 21, 2013 at 7:47 PM
Hi,

For a public facing site, you do not have much to worry about when switching the meta compatibility from IE=8 to IE=9 or IE=Edge as what breaks in SP2010 in IE9 mode would not normally be seen by anonymous users. This includes the people picker, dragging web parts to other web part zones, some ribbon issues and a few others.

Now if you want to use something like bootstrap on an Intranet or Extranet on SP2010, then you might have something to worry about. Again, if you need the people picker as well as some of the editing tools.

We really need IE9+ mode for CSS3 and media queries, but what if you didn't use media queries and instead used JavaScript to provide media query like functionality? Bootstrap wouldn't be the way to go, but you could make this responsive. You could use CSS3 Media Queries, a JavaScript plug-in that will make media queries work in older versions such as IE8. http://code.google.com/p/css3-mediaqueries-js/. It will be a mixed bag though. Very possible, just many issues that you will need to work through.
Jun 3, 2013 at 1:09 PM
Edited Jun 3, 2013 at 1:12 PM
I just wanted to add to this as I have worked hard to combat the issues that are created by setting the view engine to anything other than IE8 in SharePoint 2010.

My basic conclusion was that there were far too many unforeseen issues to justify this in any but the narrowest of cases. Here is a short list of some of the problems that I encountered:
  1. The Extended Rich Text Editor is broken by changing the View Engine to IE9 or Edge. We resolved this by adding Telerik's replacement control which is free.
  2. The people picker control malfunctions but we did find some JS hacks that seemed to mitigate this problem in IE9+ and Chrome. But the control never seemed to work perfectly.
  3. We would find other issues here and there, so many that we finally gave up on using any sort of HTML5/CSS3 in any SharePoint 2010 site that would make use of the standard UI.
  4. For user applications that required HTML5/CSS3 for rich interactions we opted to remove the SharePoint UI from the equation and use a combination of the REST API (ListData.svc) and the JavaScript CSOM. So far, this has given us all of the functionality that we need to build very rich mashups of SharePoint 2010 lists using all of the features of HTML5 and CSS3. We encountered only 2 problems and 1 restriction in doing this so far:
    4.a: You cannot change the status of Work Flow generated tasks using ListData.svc or you get a server 500 error. This seems to be a bug in the web service. Here are the details: http://sharepoint.stackexchange.com/questions/64273/listdata-svc-and-task-approval
    4.b: Due to the above you need to use the JS CSOM to perform some tasks. And in certain cases you may find it easier to use the CSOM to do certain things any way. You will need to put 5 of the SharePoint JS files into your custom ASPX page as well as include 1 SharePoint server control: http://sharepoint.stackexchange.com/questions/68633/js-csom-in-custom-html-file
    4.c You cannot use JS CSOM inside of HTML5 Web Workers because it needs access to the window object as the Type object inherits from it. But you can still use the REST API so that does give you some additional flexibility.
There are trade-offs in any path that you go down. But the fact that we can build exceptionally rich interactions and applications on SP2010 and get all the benefits of things like TypeScript, HTML5/CSS3, MVVM and build a SPA with routing those minor issues are. And the Responsive SharePoint project has really helped us customize the non-SPA pages and really modernize them to make our users happy. I hope some other users find this list of HTML5 problems useful.
Jun 5, 2013 at 12:48 AM
Wow. Thanks for the great post. I'm very interested in this approach.
Coordinator
Jun 10, 2013 at 1:38 AM
Hi Robert,

That is a very interesting approach. I really do not like having to break SharePoint to use SharePoint but I understand the frustrations and reasons you went that route. Maybe more reasons to upgrade to SharePoint 2013?

Eric