The headline is clickbaity, but the advice is solid. Use progressive enhancement and don’t worry about polyfilling.
When I say ‘Stop supporting IE’ it means to me that I won’t go the extra mile to get unsupported features working in Internet Explorer, but still make sure Internet Explorer users get the basics, and can use the site.
Keep this link handy to share with your boss or client. It is almost certainly not worth your while optimising for Internet Explorer.
Note: Google aren’t turning IE users away. Instead they’ll get a reduced scriptless experience. That’s the way to do it. Remember: module and nomodule are your friends for cutting the mustard.
Importantly, Google has not simply cut off Internet Explorer 11 from using Google Search, leaving people unable to search the web. Instead, Internet Explorer customers are now shown a rudimentary “fallback experience” for Google Search, which can perform basic searches but isn’t as fully featured as Google is on modern browsers.
The transcript from the latest episode of the HTTP 203 podcast is well worth perusing.
- Internet Explorer halted development, no innovation. Would you say Safari is the new IE?
- There was loads of stuff missing. Is Safari the new IE?
- My early career was built on knowing the bugs in IE6 and how to solve them. Is Safari the new IE?
- Internet Explorer 6, it had a really slow JavaScript engine, performance was bad in that browser. Is Safari the new IE?
- Internet Explorer had a fairly cavalier attitude towards web standards. Is Safari the new IE?
- Back in the day that we had almost no communication whatsoever. Is Safari the new IE?
- Slow-release cycle. Is Safari the new IE?
I was moaning about Safari recently. Specifically I was moaning about the ridiculous way that browser updates are tied to operating system updates.
But I felt bad bashing Safari. It felt like a pile-on. That’s because a lot of people have been venting their frustrations with Safari recently:
I think it’s good that people share their frustrations with browsers openly, although I agree with Baldur Bjarnason that’s good to avoid Kremlinology and the motivational fallacy when blogging about Apple.
It’s also not helpful to make claims like “Safari is the new Internet Explorer!” Unless, that is, you can back up the claim.
On a recent episode of the HTTP 203 podcast, Jake and Surma set out to test the claim that Safari is the new IE. They did it by examining Safari according to a number of different measurements and comparing it to the olden days of Internet Explorer. The result is a really fascinating trip down memory lane along with a very nuanced and even-handed critique of Safari.
And the verdict? Well, you’ll just to have to listen to the podcast episode.
If you’d rather read the transcript, tough luck. That’s a real shame because, like I said, it’s an excellent and measured assessment. I’d love to add it to the links section of my site, but I can’t do that in good conscience while it’s inaccessible to the Deaf community.
When I started the Clearleft podcast, it was a no-brainer to have transcripts of every episode. Not only does it make the content more widely available, but it also makes it easier for people to copy and paste choice quotes.
Still, I get it. A small plucky little operation like Google isn’t going to have the deep pockets of a massive corporation like Clearleft. But if Jake and Surma were to open up a tip jar, I’d throw some money in to get HTTP 203 transcribed (I recommend getting Tina Pham to do it—she’s great!).
I apologise for my note of sarcasm there. But I share because I care. It really is an excellent discussion; one that everyone should be able to access.
Update: the bug with that episode of the HTTP 203 podcast has been fixed. Here’s the transcript! And all future episodes will have transcripts too:
Some folks called us out for lacking transcripts for our podcasts. Fair point! So, here we go (and all future episodes will have transcripts)https://t.co/HmfwBvAicA
— Jake Archibald (@jaffathecake) August 18, 2021
Any time or effort spent getting your JavaScript working in IE11 is wasted time that could be better spent making a better experience for users without JavaScript.
I agree with this approach.
With a few minor omissions and links, you can create a site that works great in modern browsers with ES6+ and acceptably in browsers without JavaScript. This approach is more sustainable for teams without the resources for extensive QA, and more beneficial to users of nonstandard browsers. Trying to recreate functionality that already works in modern browsers in IE11 is thankless work that is doomed to neglect.
I really enjoyed this trip down memory lane with Chris:
From the Web’s inception, an ancient to contemporary history of the Web.
What you see is the big map of a sea of literature, one where each island represents a single author, and each city represents a book. The map represents a selection of 113 008 authors and 145 162 books.
This is a poetic experiment where we hope you will get lost for a while.
Supporting Internet Explorer 11 doesn’t mean you need to give it the same experience as a modern browser:
Making sure (some of) your code works in older browsers, does not mean all functionality has to work everywhere. But, mind you, ninety percent of web development means putting text and images in boxes.
And to be honest, there is no reason to not enable this everywhere. Same for form submissions. Make it boring. Make it solid. And sprinkle delight on it.
With a Progressive Enhancement mindset, support actually means support. We’re not trying to create an identical experience: we’re creating a viable experience instead.
Also with Progressive Enhancement, it’s incredibly likely that your IE11 user, or your user on a low-powered device, or even your user on a poor connection won’t notice that they’re experiencing a “minor” experience because it’ll just work for them. This is the magic, right there. Everyone’s a winner.
An interesting look at the mortality causes for Internet Explorer 6 and Internet Explorer 8, and what they can tell us for the hoped-for death of Internet Explorer 11.
I disagree with the conclusion (that we should actively block IE11—barring any good security reasons, I don’t think that’s defensible), but I absolutely agree that we shouldn’t be shipping polyfills in production just for IE11. Give it your HTML. Give it your CSS. Withhold modern JavaScript. If you’re building with progressive enhancement (and you are, right?), then giving IE11 users a sub-par experience is absolutely fine …it’s certainly better than blocking them completely.
This is a terrific spot-on piece by Rachel. I firmly believe that healthy competition and diversity in the browser market is vital for the health of the web (which is why I’m always saddened and frustrated to hear web developers wish for a single monocultural rendering engine).
Oliver Williams makes the case—and shows the code—for delivering only HTML to old versions of Internet Explorer, sparing them from the kind of CSS and JavaScript that they can’t deal with it. Seems like a sensible approach to me (assuming you’re correctly building in a layered way so that your core content is delivered in markup).
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.
This is a fascinating way to explore time and place—a spyglass view of hundred year old maps overlaid on the digital maps of today.
Oh, this is going to be so useful to future me! Sarah has put together a handy guide to all the JavaScript methods for manipulating arrays.
I like this. It fills like a very webby way to explore a museum collection. Use any axis you like.
This is a sketch made quickly to explore what it means to navigate a museum catalogue made of over two million records. It’s about skipping around quickly, browsing the metadata as if you were wandering around the museum itself in Bloomsbury, or better yet, fossicking about unattended in the archives.
This a great step-by-step walkthrough from Rey on setting up a remote version of Internet Explorer for testing on Mac.
One more reason why you should never sniff user-agent strings: Internet Explorer is going to lie some more. Can’t really blame them though—if developers didn’t insist on making spurious conclusions based on information in the user-agent string, then browsers wouldn’t have to lie.
Oh, and Internet Explorer is going to parse -webkit prefixed styles. Again, if developers hadn’t abused vendor prefixes, we wouldn’t be in this mess.
A nice stroll around Marseilles at night without any of the traditional danger.
A good explanation of the litany of woes that comes from Internet Explorer 8 being the highest that users of Windows XP can upgrade to. It’s a particularly woeful situation if you are a web developer attempting to provide parity. But there is hope on the horizon:
2013 will see the culmination of all these issues; support for IE 8 will drop of rapidly, users of XP will find an increasingly broken web, the cost of building software in XP organisations will increase.
People have been linking to—and saying nice things about—my musings on dealing with Internet Explorer. Thank you. You’re very kind. But I think I should clarify a few things.
If you’re describing the techniques I showed (using Sass and conditional comments) as practical or useful, I appreciate the sentiment but personally I wouldn’t describe them as either. Jake’s technique is genuinely useful and practical.
I wasn’t really trying to provide any practical “take-aways”. I was just thinking out loud. The only real point to my ramblings was at the end:
When we come up with clever hacks and polyfills for dealing with older versions of Internet Explorer, we shouldn’t feel pleased about it. We should feel angry.
My point is that we really shouldn’t have to do this. And, in fact, we don’t have to do this. We choose to do this.
Take the particular situation I was describing with a user of The Session who using IE8 on Windows XP with a monitor set to 800x600 pixels. A lot people picked up on this observation:
As a percentage, this demographic is tiny. But this isn’t a number. It’s a person. That person matters.
But here’s the thing: that person only started to experience problems when I chose to try to “help” IE8 users. If I had correctly treated IE8 as the legacy browser that it is, those users would have received the baseline experience …which was absolutely fine. Not great, but fine. But instead, I decided to jump in with my hacks, my preprocessor, my conditional comments, and worst of all, my assumptions about the viewport size.
In this case, I only have myself to blame. This is a personal project so I’m the client. I decided that I wanted to give IE8 and IE7 users the same kind of desktop navigation that more modern browsers were getting. All the subsequent pain for me as the developer, and for the particular user who had problems, is entirely my fault. If you’re working at a company where your boss or your client insists on parity for IE8 or IE7, I guess you can point the finger at them.
My point is: all the problems and workarounds that I talked about in that post were the result of me trying to crowbar modern features into a legacy browser. Now, don’t get me wrong—I’m not suggesting that IE8 or IE7 should be shut out or get a crap experience: “baseline” doesn’t mean “crap”. There’s absolutely nothing wrong with serving up a baseline experience to a legacy browser as long as your baseline experience is pretty good …and it should be.
So, please, don’t think that my post was a hands-on, practical example of how to give IE8 and IE7 users a similar experience to modern browsers. If anything, it was a cautionary tale about why trying to do that is probably a mistake.