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.
JavaScript doesn’t get executed on very old browsers when native syntax for new language features is encountered. However, thanks to GitHub being built following the principle of progressive enhancement, users of older browsers still get to interact with basic features of GitHub, while users with more capable browsers get a faster experience.
That’s the way to do it!
Concepts like progressive enhancement allow us to deliver the best experience possible to the majority of customers, while delivering a useful experience to those using older browsers.
Read on for the nitty-gritty details…
This is a great succinct definition of progressive enhancement:
Progressive enhancement is a web development strategy by which we ensure that the essential content and functionality of a website is accessible to as many users as possible, while providing an improved experience using newer features for users whose devices are capable of supporting them.
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.
…you would be forgiven if you saw an API where a feature went from green (supported) to red (unsupported) and you thought: is the browser being deprecated?
That’s the idea behind my new shiny domain: canistilluse.com. I made the site as satire after reading Jeremy Keith’s insightful piece where he notes:
the onus is not on web developers to keep track of older features in danger of being deprecated. That’s on the browser makers. I sincerely hope we’re not expected to consult a site called canistilluse.com.
It’s weirdly gratifying to see a hastily-written sarcastic quip tuned into something real.
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.
This is a very handy table of elements from Steve of where aria-label can be applied.
Like, for example, not on a div element.
A very handy community project that documents support for ARIA and native HTML accessibility features in screen readers and browsers.
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.
Rachel follows up on my recent post about CSS grid in old IE with her thoughts.
As Jeremy notes, the usefulness of a tool like Autoprefixer is diminishing, which is a good thing. It is becoming far easier to code in a way that supports all browsers, where support means usable in an appropriate way for the technology the user has in front of them. Embrace that, and be glad for the fact that we can reduce complexity based on the increasing interoperability of CSS in our browsers.
A great in-depth report from Alice on creating, running, and most importantly, selling an in-house design system. This makes a great companion piece to her Patterns Day talk.
Where internal teams seem to go wrong is not appreciating that the thing they’re building is still a product and so it needs to compete with other products on the market.
24 Ways is back! Yay! This year’s edition kicks off with a great article by Hui Jing on using @supports:
Chances are, the latest features will not ship across all browsers at the same time. But you know what? That’s perfectly fine. If we accept this as a feature of the web, instead of a bug, we’ve just opened up a lot more web design possibilities.
Smashing Magazine has launched its lovely new design, but more importantly, it has launched its lovely new business model. Ads are gone. Patronage is in. This is a resource worth supporting.
We’re getting rid of advertisers and digging back to our roots: community-based, community-built, and determinedly non-commercial.
I approve!
A List Apart has given me so, so much over the years that becoming a supporter is quite literally the least I can do.
Oh, how I wish I could’ve been at Web Directions Code in Melbourne to see this amazing presentation by Charlotte. I can’t quite get over how many amazing knowledge bombs she managed to drop in just 20 minutes!
Donate money to support Codebar:
By donating to codebar you are helping to promote diversity in the tech industry so that more women, LGBTQA and other underrepresented folks will be able to get started with programming and raise their skills to the next level.
Thanks to jQuery, you probably don’t need jQuery. Just look at all these methods that started life in jQuery, that are now part of the standardised DOM API:
remove()prepend()before()replaceWith()closest()This resonates a lot—we’ve been working on something similar at Clearleft, for very similar reasons:
We rode the folk knowledge train until it became clear that it was totally unscaleable and we struggled to effectively commute know-how to the incoming brains.
At Made By Many, they’ve sliced it into three categories: Design, Technology, and Product Management & Strategy. At Clearleft, we’re trying to create a skills matrix for each of these disciplines: UX, UI, Dev, Research, Content Strategy, and Project Management. I’m working on the Dev matrix. I’ll share it once we’ve hammered it into something presentable. In the meantime, it’s good to see exactly the same drivers are at work at Made By Many:
The levels give people a scaffold onto which they can project their personalised career path, reflecting their progression, and facilitating professional development at every stage.
You can help support the indie web community with their fairly modest costs: about $200 each month for hosting, domain names, and the like. Also:
We want IndieWeb events to be as accessible as possible, regardless of personal barriers. Because of this, we have offered a travel scholarship fund in the past to underrepresented groups thanks to our generous sponsors. Your support will allow us to continue to offer and expand this scholarship fund, helping make sure that IndieWebCamps represent everyone.