Working With Internet Explo{d,r}er 9

Lately I’ve been working with Web Components in my spare time and recently I was moved to the Engineering group at 3Pillar. At work I have been challenged by the limitations of Internet Explorer 9 (IE9). Many of our clients still support browsers like IE9 and much of the corporate and government world use browsers that have been locked down to certain versions either because of the Hacker News propaganda and paranoia with security/privacy issues in browsers or just because ‘Big Brother’ said so. In fact, the corporate world seems to prefer the ‘security’ & ‘privacy’ of Internet Explorer. Many features in browsers that are not named ‘Internet Explorer’ are disabled and system administrators will sometimes lock down everything ‘just to be sure’. Internet Explorer itself gets locked down as well. Perhaps it is the “clear” internet options that integrate so well in their ‘secure’ windows environment.

Now that I am part of the Engineering group I have client work that has a real need to work with older browsers as opposed to the cutting edge prototype work I was doing previously with the User Experience group. It has been a while since I had to break out my cross-browser bug smashing mind and I was very excited that I did not have to worry about IE9’s cleverly named predecessor – Internet Explorer 8.

Some of the pain I encountered in IE8 has been extreme and frustrating to say the least. At first I compared it to IE7 and justified the abuse much like a battered victim would. After all, it supported CSS data-uri’s, I had no more float or double margin issues, hasLayout worked a bit better….I am sure there is more but that’s about the sum of it. IE8, like it’s father before him, had extreme issues with lazy loading and script performance. Internet Explorer 8 and older versions have been using JScript, which is a variant of JavaScript that is non-standard and proprietary to Microsoft. IE9 is the first of the IE browser family to use standard JavaScript.

Internet Explorer has had a history of CSS issues solved with expressions filter rules. These work but are highly toxic to performance. Rendering times are significantly higher when using these, so don’t if you can help it.  The most obnoxious piece of IE8 (and IE7) with regards to CSS are it’s request and file size limitations.

Internet Explorer 7

  • Maximum Stylesheet Size Limit: 288kb per file
  • Maximum number of CSS Stylesheets:  30 files.

Internet Explorer 8

  • Maximum Stylesheet Size Limit: 288kb per file
  • Maximum number of CSS Stylesheets:  30 files.

Internet Explorer 9

  • Maximum Stylesheet Size Limit: not tested yet
  • Maximum number of CSS Stylesheets:  30 files.

Internet Explorer 10

  • Maximum Stylesheet Size Limit: not tested yet
  • Maximum number of CSS Stylesheets:  not tested yet

Other limitations that are less significant with regards to CSS are the rule counts, import counts, and import nesting levels. While these numbers may seem unreachable – consider the misuse of CSS Preprocessors on a team of 20-30. It has happened before and hopefully we are now writing CSS in a style like OOCSS or SMACSS to avoid this.
Internet Explorer 6-9

  • A sheet may contain up to 4095 rules
  • A sheet may @import up to 31 sheets
  • @import nesting supports up to 4 levels deep

Internet Explorer 10

  • A sheet may contain up to 65534 rules
  • A document may use up to 4095 stylesheets
  • @import nesting is limited to 4095 levels (due to the 4095 stylesheet limit)

The worst part about these limitations is that no errors or information is sent to the users. In fact, when Internet Explorer parses a CSS file and reaches its maximum kilobyte size, it just stops parsing it. The request is still a 200 but suddenly some CSS rules are missing. When minifying and concatenating files, as current best practice would probably warrant, this becomes a debugging nightmare unless you know that these limitations exist.

IE9 has full support for SVG (Scalable Vector Graphics)! Prior to IE9, the browser used it’s own variant of SVG called VML. Charting libraries had limited support for VML so this is great that SVG is finally native in IE. IE9 also has full CSS support for Media Queries but that only includes CSS rules. Keep in mind that the JavaScript “window.matchMedia” method does not work. IE9 does not support “Element.classList” which is frustrating if you don’t want to use JQuery. IE9 does have partial support for Viewport Units which is helpful but not as flexible as we need. Pointer Events require a polyfill as they are not supported as well. Combine that with bugging CSS Appearance rules and styling form elements still sucks really bad. As far as layout goes, I have had no luck getting Flexbox polyfills to work in IE9 so “display: table” or floats seem the only semi-sane way for go. IE8 and IE9 have issues with cross origin resource sharing & CSP as well. The typical scenario occurs with icon fonts from Google Fonts are not loaded but cross domain issues are not limited to this particular case. IE8 & IE9 get buggy partial support for this using ‘XDomainRequest’ and the majority of polyfills require you have access to the origin server…gee, that’s useful.

To Sum up…IE9 IS the new IE8. Like IE8, it adds a huge amount of development overhead when developing for rich and performant applications. Consider burying it alive if you can. Here are some tests to visualize some of the CSS issues.