My first full-time developer job was at a small company. We didn’t have BrowserStack, so we cobbled together a makeshift device lab. Viewing a site I’d been making on a busted first-generation iPad with an outdated version of Safari, I saw a distorted, failed mess. It brought to me a quote from Douglas Crockford, who once deemed the “the most hostile software engineering environment imaginable.”

The “works best with Chrome” problem

Continues Below

Because of this difficulty, a problem has emerged. Earlier this year, a widely shared article in the Verge warned of “works best with Chrome” messages seen around the web.

There are more examples of this problem. In the popular messaging app Slack, voice calls work only in Chrome. In response to help requests, Slack explains its decision like this: “It requires significant effort for us to build out support and triage issues on each browser, so we’re focused on providing a great experience in Chrome.” (Emphasis mine.) Google itself has repeatedly built sites—including Google Meet, Allo, YouTube TV, Google Earth, and YouTube Studio—that block alternative browsers entirely. This is clearly a bad practice, but highlights the fact that cross-browser compatibility can be difficult and time-consuming.

The significant feature gap, though, isn’t between Chrome and everything else. Of far more significance is the increasingly gaping chasm between Explorer and every other major browser. Should our development practices be hamstrung by the past? Or should we dash into the future relinquishing some users in our wake? I’ll argue for a middle ground. We can make life easier for ourselves without breaking the backward compatibility of the web.

The widening gulf

Chrome, Opera, and Firefox ship new features constantly. Edge and Safari eventually catch up. Internet Explorer, meanwhile, has been all but abandoned by Microsoft, which is attempting to push Windows users toward Edge. IE receives nothing but security updates. It’s a frustrating period for client-side developers. We read about new features but are often unable to use them—due to a single browser with a diminishing market share.

A graph showing Internet Explorer’s global market share from 2013 to 2018. It has declined from about 23 percent to about 3 percent.  - fig1 - The Slow Death of Internet Explorer and the Future of Progressive Enhancement · An A List Apart Article
Internet Explorer’s global market share since 2013 is shown in blue. It now stands at just 3 percent.

Some new features are utterly trivial (caret-color!); some are for particular use cases you may never have (WebGL 2.0, Web MIDI, Web Bluetooth). Others already feel near-essential for even the simplest sites (object-fit, Grid).

A list from of features that are supported in Chrome but unavailable in IE11. This is a truncated and incomplete screenshot of an extraordinarily long list.  - fig2 - The Slow Death of Internet Explorer and the Future of Progressive Enhancement · An A List Apart Article
A list of features supported in Chrome but unavailable in IE11, taken from This is a truncated and incomplete screenshot of an extraordinarily long list.

The promise and reality of progressive enhancement

For content-driven sites, the question of browser support should never be answered with a simple yes or no. CSS and HTML were designed to be fault-tolerant. If a particular browser doesn’t support shape-outside or service workers or font-display, you can still use those features. Your website will not implode. It’ll just lack that extra stylistic flourish or performance optimization in non-supporting browsers.

Other features, such as CSS Grid, require a bit more work. Your page layout is less enhancement than necessity, and Grid has finally brought a real layout system to the web. When used with care for simple cases, Grid can gracefully fall back to older layout techniques. We could, for example, fall back to flex-wrap. Flexbox is by now a taken-for-granted feature among developers, yet even that is riddled with bugs in IE11.

.grid > * {
    width: 270px; /* no grid fallback style */
    margin-right: 30px; /* no grid fallback style */

@supports (display: grid) {
.grid > * {
	width: auto;
	margin-right: 0;

In the code above, I’m setting all the immediate children of the grid to have a specified width and a margin. For browsers that support Grid, I’ll use grid-gap in place of margin and define the width of the items with the grid-template-columns property. It’s not difficult, but it adds bloat and complexity if it’s repeated throughout a codebase for different layouts. As we start building entire page layouts with Grid (and eventually display: contents), providing a fallback for IE will become increasingly arduous. By using @supports for complex layout tasks, we’re effectively solving the same problem twice—using two different methods to create a similar result.

Not every feature can be used as an enhancement. Some things are imperative. People have been getting excited about CSS custom properties since 2013, but they’re still not widely used, and you can guess why: Internet Explorer doesn’t support them. Or take Shadow DOM. People have been doing conference talks about it for more than five years. It’s finally set to land in Firefox and Edge this year, and lands in Internet Explorer … at no time in the future. You can’t patch support with transpilers or polyfills or prefixes.

Users have more browsers than ever to choose from, yet IE manages to single-handedly tie us to the pre-evergreen past of the web. If developing Chrome-only websites represents one extreme of bad development practice, shackling yourself to a vestigial, obsolete, zombie browser surely represents the other.

The problem with shoehorning

Rather than eschew modern JavaScript features, polyfilling and transpiling have become the norm. ES6 is supported everywhere other than IE, yet we’re sending all browsers transpiled versions of our code. Transpilation isn’t great for performance. A single five-line async function, for example, may well transpile to twenty-five lines of code.

“I feel some guilt about the current state of affairs,” Alex Russell said of his previous role leading development of Traceur, a transpiler that predated Babel. “I see so many traces where the combination of Babel transpilation overhead and poor [webpack] foo totally sink the performance of a site. … I’m sad that we’re still playing this game.”

What you can’t transpile, you can often polyfill. has become massively popular. Chrome gets sent a blank file. Ancient versions of IE receive a giant mountain of polyfills. We are sending the largest payload to those the least equipped to deal with it—people stuck on slow, old machines.

What is to be done?

Prioritize content

Cutting the mustard is a technique popularized by the front-end team at BBC . The approach cuts the browser market in two: all browsers receive a base experience or core content. JavaScript is conditionally loaded only by the more capable browsers. Back in 2012, their dividing line was this:

if ('querySelector' in document && 'localStorage' in window && 'addEventListener' in window) {
     // load the javascript

Tom Maslen, then a lead developer at the BBC, explained the rationale: “Over the last few years I feel that our industry has gotten lazy because of the crazy download speeds that broadband has given us. Everyone stopped worrying about how large their web pages were and added a ton of JS libraries, CSS files, and massive images into the DOM. This has continued on to mobile platforms that don’t always have broadband speeds or hardware capacity to render complex code.”

The Guardian, meanwhile, entirely omits both JavaScript and stylesheets from Internet Explorer 8 and further back.

A screenshot of the Guardian navigation as seen in Internet Explorer 8, showing a list of links stripped of the site’s visual design.  - fig3 - The Slow Death of Internet Explorer and the Future of Progressive Enhancement · An A List Apart Article
The Guardian navigation as seen in Internet Explorer 8. Unsophisticated yet functional. takes a similar approach, delivering only a very limited stylesheet to anything older than IE10.

The homepage as seen in Internet Explorer 9, showing only a minimal visual design.  - fig4 - The Slow Death of Internet Explorer and the Future of Progressive Enhancement · An A List Apart Article
The homepage as seen in Internet Explorer 9.

Were you to break into a museum, steal an ancient computer, and open Netscape Navigator, you could still happily view these websites. A user comes to your site for the content. They didn’t come to see a pretty gradient or a nicely rounded border-radius. They certainly didn’t come for the potentially nauseating parallax scroll animation.

Anyone who’s been developing for the web for any amount of time will have come across a browser bug. You check your new feature in every major browser and it works perfectly—except in one. Memorizing support info from and using progressive enhancement is no guarantee that every feature of your site will work as expected.

A screenshot of the W3C’s website for the CSS Working Group as viewed in the latest version of Safari, showing overlapping, unreadable text.  - fig5 - The Slow Death of Internet Explorer and the Future of Progressive Enhancement · An A List Apart Article
The W3C’s website for the CSS Working Group as viewed in the latest version of Safari.

Regardless of how perfectly formed and well-written your code, sometimes things break through no fault of your own, even in modern browsers. If you’re not actively testing your site, bugs are more likely to reach your users, unbeknownst to you. Rather than transpiling and polyfilling and hoping for the best, we can deliver what the person came for, in the most resilient, performant, and robust form possible: unadulterated HTML. No company has the resources to actively test their site on every old version of every browser. Malfunctioning JavaScript can ruin a web experience and make a simple page unusable. Rather than leaving users to a mass of polyfills and potential JavaScript errors, we give them a basic but functional experience.

Make a clean break

What could a mustard cut look like going forward? You could conduct a feature query using JavaScript to conditionally load the stylesheet, but relying on JavaScript introduces a brittleness that would be best to avoid. You can’t use @import inside an @supports block, so we’re left with media queries.

The following query will prevent the CSS file from being delivered to any version of Internet Explorer and older versions of other browsers:

<link id="mustardcut" rel="stylesheet" href="stylesheet.css" media="
    only screen,
    only all and (pointer: fine), only all and (pointer: coarse), only all and (pointer: none),
    min--moz-device-pixel-ratio:0) and (display-mode:browser), (min--moz-device-pixel-ratio:0)

We’re not really interested in what particular features this query is testing for; it’s just a hacky way to split between legacy and modern browsers. The shiny, modern site will be delivered to Edge, Chrome (and Chrome for Android) 39+, Opera 26+, Safari 9+, Safari on iOS 9+, and Firefox 47+. I based the query on the work of Andy Kirk. If you want to take a cutting-the-mustard approach but have to meet different support demands, he maintains a Github repo with a range of options.

We can use the same media query to conditionally load a Javascript file. This gives us one consistent dividing line between old and modern browsers:

(function() {
	var linkEl = document.getElementById('mustardcut');
	if (window.matchMedia && window.matchMedia( {
    	var script = document.createElement('script');
    	script.src = "";
    	script.async = true;

matchMedia brings the power of CSS media queries to JavaScript. The matches property is a boolean that reflects the result of the query. If the media query we defined in the link tag evaluates to true, the JavaScript file will be added to the page.

It might seem like an extreme solution. From a marketing point of view, the site no longer looks “professional” for a small amount of visitors. However, we’ve managed to improve the performance for those stuck on old technology while also opening the possibility of using the latest standards on browsers that support them. This is far from a new approach. All the way back in 2001, A List Apart stopped delivering a visual design to Netscape 4. Readership among users of that browser went up.

Front-end development is complicated at the best of times. Adding support for a technologically obsolete browser adds an inordinate amount of time and frustration to the development process. Testing becomes onerous. Bug-fixing looms large.

By making a clean break with the past, we can focus our energies on building modern sites using modern standards without leaving users stuck on antiquated browsers with an untested and possibly broken site. We save a huge amount of mental overhead. If your content has real value, it can survive without flashy embellishments. And for Internet Explorer users on Windows 10, Edge is preinstalled. The full experience is only a click away.

A screenshot of the A List Apart masthead open in Internet Explorer 11, showing the ever-present Internet Explorer button that reads Open Microsoft Edge.  - fig6 - The Slow Death of Internet Explorer and the Future of Progressive Enhancement · An A List Apart Article
Internet Explorer 11 with its ever-present “Open Microsoft Edge” button.

Developers must avoid living in a bubble of MacBook Pros and superfast connections. There’s no magic bullet that enables developers to use bleeding-edge features. You may still need Autoprefixer and polyfills. If you’re planning to have a large user base in Asia and Africa, you’ll need to build a site that looks great in Opera Mini and UC Browser, which have their own limitations. You might choose a different cutoff point for now, but it will increasingly pay off, in terms of both user experience and developer experience, to make use of what the modern web has to offer.


Source link


Please enter your comment!
Please enter your name here