I typically take a conservative approach to building websites, layering in modern functionality in order to reduce code and technical debt and extend my client’s investment further into the future. A recent project uses Grid with Flexbox fallbacks and minimal ES6 features that are all ran through Autoprefixer and Babel for maximum automated compatibility.

Despite my safeguarding, the site crumbled and was completely unusable in IE91. Of course I took to Twitter…

Twitter Polls are cathartic, but maybe not useful. In order to better diagnose and understand its challenges, I started making a list of my biggest roadblocks with IE9. I also want to break this conversation out of the classic “IE SUCKS” trope and focus more on the technical deficiencies.

The Missing Styles

There are lots of things missing from IE9, but in my mind there are a few key missing HTML/CSS features that make modern web development difficult. From a styling perspective, these hurt the most:

  • No Flexbox
  • No <input placeholder>
  • No @supports

A missing feature is not really a knock; IE9 launched in 2011 and @supports didn’t exist, placeholder was maybe a nice to have, and the Flexible Box specification was Webkit-only and in a weird “tweener phase”. But the lack of these features create a lot of workarounds.

Lack of Flexbox is by far the biggest style compat issue in IE9. Flexbox only stabilized in 2013, but it’s already an essential tool in how I layout components. float and inline-block baselines create artifacts (like margin and width rules) that must be unset in order for Flexbox to work. The “enhancement” path comes coupled with a bunch of overrides. This makes code harder to maintain and makes design changes more difficult going forward.

No placeholder create problems for designers who make label-less forms. I typically always advocate for using label, but placeholder is very useful in inline form situations (e.g. Search, Email/SMS capture, etc). Placeholder polyfills exist, but I still have emotional baggage from trying to use them.

If @supports existed, we’d have panacea, but that would be too easy…

The Polyfills

Some missing features can be polyfilled.

  • No classList.add() and classList.remove()
  • No matchMedia()
  • No <picture>
  • No requestAnimationFrame()
  • No External SVG Content

There are some other things like contains() and matches() but we can invoke JavaScript’s quirkiest functor, indexOf(), for an easy workaround. It returns -1 when false.. bless its heart.

Polyfills are a great and somewhat neutral way to opt-in to non-ubiquitous features. But they come with kilobyte, parsing, and execution overhead that synchronously blocks execution of user-relevant code. Normally this isn’t a big deal, but when you’re thread-blocking all mobile users for a very thin slice of desktop users, I start to reconsider the payoff.

The Broken Security Model

This is maybe the most significant part of the debate. IE9 has a fundamentally broken security model that puts users at risk.

  • No TLS 1.1/1.2/1.3
  • No Strict Transport Security
  • No Content Security Policy 1.0/2.0

Security is a major concern and IE9 leaves users quite exposed2. Here’s the crux of my question: Do we harm users by enabling older browsers? Harm might be too strong a word, but I liken it to having an alcoholic grandfather and still feeling compelled to stock the liquor cabinet.

I think about this a lot. I believe the web should work everywhere, but is that a naive goal when people’s privacy and credit cards are at risk? Do I have an ethical responsibility to discourage this browser from browsing? Is that being non-inclusive? Am I violating POUR?

If it’s a simple non-transactional blog post or flan recipe, I suppose it should render, but once again it’s naive to assume that recipe websites don’t also come with a few hundred third-party domains worth of tracking scripts. On an e-commerce site, funneling a user to checkout, but not allowing a transaction seems non-idyllic.

I think this is an important consideration and I’d love people smarter than me (specifically, browser security people) to weigh in on this.

The Dev Tooling

The last problem in the puzzle is IE9’s F12 Developer Tools aren’t that great. Although it was the start of a new era for F12 Developer Tools, clicking through the tool is quite clumsy. I hate to critique 6 year old dev tools, but the icons are unlabeled and you can’t reliably add styles in the inspector. This makes fixing problems more difficult and time consuming, thus more expensive.

To support or not to support?

Usually the answer to this question is a version Brad Frost’s “Support vs. Optimization”, which generally I agree with, but the line for what is considered “broken” is fuzzy. How visually broken does it have to be in order to be functionally broken? I look for cheap fixes, but this is compounded by the fact the offshore QA team doesn’t abide in that nuance, a defect is a defect, which gets logged and assigned to my inbox and pollutes the backlog. Will future developers understand my decisions there?

We’ve put a few weeks into fixing/optimizing for IE9. This has brought about a lot of discussions about the financial and technical cost of supporting IE9. Whether it’s polyfills, rogue if-statements, phantom styles, or QA kickbacks; there are costs and technical debt associated with rendering this site on an ever-dwindling sliver of browsers.

Thankfully my client has analytics that can put a dollar amount on IE9 traffic which helps the discussion immensely. On the plus side while it feels like I’m toiling on optimizing for one waning browser, I’m broadening and bulletproofing support for an untold number of random browsers (I’m looking at you Amazon Silk).

  1. Full disclosure: I was paid by Microsoft in 2011 to build Lost World’s Fairs, a website to celebrate the launch of IE9. ↩

  2. Windows Vista SP2 was EOL’d in April 2017. IE9 users on Windows 7 users should have been auto-upgraded to IE11. This does not account for rogue Document Modes nor enterprise companies who have made themselves less secure by disabling auto-updates. ↩