Media webpart dependent on older IE versions

When last year we brought our new SharePoint 2013 based intranet life, the company standard browser was still IE9 (the reason in some non-Microsoft webapplicaties, that exposed an hard reliance on older IE version). End 2015 we could move/upgrade to IE11. Today I received a signal from a content owner that the standard Media webpart can not be configured via the ribbon - the Media tab does not popup. I googled and tried some, to find out that this is due the IE upgrade. It appears that the standard Media webpart also has a dependency on older IE version. Pragmatic workaround for content owners is to emulate IE8 via F12 Developer Tools. This is an acceptable workaround for now, as our structural mitigation is to step away from the standard Media webpart (with a reliance on Silverlight) in favor of an html5 based setup, using Video.js library.

Tip: HowTo mitigate impact of IE8/IE9 style-tag limit

Many organizations still have IE8 or IE9 as standard browser installed on their employee workstations. Internet Explorer versions before IE10 have an hard boundary on the maximum number of stylelink imports that are applied, namely 31 (see Microsoft Support: 'A webpage that uses CSS styles does not render correctly in Internet Explorer'). Imported link-entries beyond that maximum are effectively ignored in the IE8/IE9 output rendering. This results in missing a part of the applied CSS-styling, and different rendering in IE8/IE9 compared to other browsers (FireFox, Chrome, Safara, IE10/11). The limit of 31 seems large enough, or stated differently: that you would need more than 31 seems ridiculous and unmanageable. But be aware that in the concept of SharePoint, content editors compose functional experiences by placing multiple and mutual independent webparts on SharePoint content pages. These webparts - common-of-the-shelf (Microsoft, any from the large SharePoint community), or custom build - are self-contained, also for their CSS styling. Also the standard SharePoint:CssLink already adds (consumes) 4 css-link imports to the generated page html. So when multiple webparts added to a page, the limit of 31 link-entries in the total page html can certainly be exceeded.

The IE8/IE9 link-limit is an hard number, not possible to increase that. If it is not yet possible or not planned for an organization to migrate to a later IE version (or another browser), you must apply an approach to mitigate the impact of the link-limit. For a part this can be achieved by collapsing multiple link-references within one 'style' island in the outputted html. IE8/IE9 regards plus applies that as only one single style element, and this way you can have multiple link-imports that together only consume 1 of the 31 available stylelink-slots.

Example:

Replace:

<SharePoint:CssRegistration Name="<%$SPUrl:~SiteCollection/Style Library/css/cssfile1.css%>" runat="server"/>
<SharePoint:CssRegistration Name="<%$SPUrl:~SiteCollection/Style Library/css/cssfile2.css%>" runat="server"/>
...

Into:

<style type="text/css">
<!--
@import url("../../cssfile1.css");
@import url("../../cssfile2.css");
...
-->
</style>

This approach is not the silver bullet to 100% circumvent the hard-imposed IE8/IE9 style-tag limit, but it might save you just sufficiently on occupied stylelink slots to leave sufficient slots for the COTS webparts placed on a page. This was so for myself in a customer project with a COTS SharePoint-based product implementation.

Note:
It is also good to realize that IE8/IE9 emulation modus in IE10 and later, does not impose the link limit. And therefore on this aspect the IE8/IE9 emulation will be different than browsing from real IE8/IE9 browsers.

Tip - solve DateTimeControl's datepickerframe positioning fault for IE8

The SharePoint DateTimeControl uses clientside javascript to runtime position the datepickerframe nearby the imagebutton. When browsing via IE8, the frame is however positioned incorrect, at a visually unrelated position.

I inspected the SharePoint datepicker.js client library from the 12hive\layouts folder to locate the cause of this. At first I had the impression that it was due to the usage of dynamic properties (pixelTop, pixelLeft, pixelRight). As of IE8, DynamicProperties are namely no longer supported to comply with CSS standards.

The real cause however is the usage of the offsetParent method to calculcate the display position for the popped-up datepickerframe. It appears that IE8 returns another value for this method than earlier IE versions for hidden objects: they all return the document.body object as their offsetParent. This causes the pickerdateframe to be displayed at an unexpected place.

A quick fix is to force the browser in IE7 emulation mode in the HTML header:

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

A more elegant fix is correctly position the frame by circumventing the offsetParent malfunctioning. I solved the problem by runtime extending the standard 'clickDatePicker' method, and so make sure that for IE8 the datepickerframe.style.display is unequeal 'none' upon requesting it's offsetParent.

Tip - jQuery setExpression and IE8

I ran today into a jQuery exception when testing a WebPart on a system with IE8 installed. In the custom WebPart I apply jQuery a.o. to round buttons and grid-headers. I'm utilizing jquery.corner.js for this. It appears that of IE8, Internet Explorer no longer supports dynamic properties. To prevent the Javascript exception, I made a small modification into 'jquery.corner.js' to check on the IE-version:

if (($.browser.msie) && ($.browser.version < 8.0))
    ds.setExpression('width', 'this.parentNode.offsetWidth');