Material-ui: [RFC] Stop IE 11 support

[oliviertassinari]

Internet Explorer 11 market share is rapidly decreasing.

Source

Soon or latter, we should be able to drop it. Removing the support for this browser, will enable us to remove some code (32 edge cases). It would also enable us the usage of CSS variables. I would like to experiment on CSS variables support for the theme before that. It could be a great alternative to style functions and dynamic themes.

Regarding the timing, should we do it in 2019, 2020, 2021 or later?

[joshwooding]

I wouldn’t want this in v4, v5 or later would be better

[mbrookes]

Just for reference, end of support for IE11 is May 11, 2021 (Windows 10 EOS, excluding LTS versions). https://support.microsoft.com/en-us/help/13853/windows-lifecycle-fact-sheet

[oliviertassinari]

I'm adding the v5 milestone. Let's check again the market share in 1 year from now.

[Studio384]

Just for reference, end of support for IE11 is May 11, 2021 (Windows 10 EOS, excluding LTS versions). https://support.microsoft.com/en-us/help/13853/windows-lifecycle-fact-sheet

This deadline is moved up every 6 months by another 6 months and as long as IE11 remains part of Windows it will be supported. The current deadline is actually January 2029 (January 2024 if you want to ignore businesses).

[mbrookes]

The _current_ deadline is actually January 2029

That's why I said _excluding_ LTS. If companies wish to pay for LTS for Windows 10 (ergo IE 11), they're welcome to pay for LTS for Material-UI. 😄

[GitTom]

As the gap grows between the evergreen browsers and IE11 the pressure will increase to abandon IE11 so the rate at which IE11 is being dropped should accelerate. I'm seeing conservative Enterprises adopt policies whereby users have access to IE11 for legacy apps but use Chrome for everything else.

I think it should also be taken into account that the changes being discussed now (for v4) won't be released for X months, at which time new products will start to be based on it, which will be released and begin their active lifecycle another Y months later. And even then, projects that still need to support IE can keep using v3.

I think the bootstrap people had the problem that they didn't think they could depend on flexbox for their v4, but as their development slowly moved forward, the browser market also moved forward, so they had to revisit that important decision.

[oliviertassinari]

@GitTom I agree with your analysis. We have been planning the breaking changes of v4 for a long time. Executing them shouldn't take more than 1-2 months. People should be able to upgrade easily. We will try to provide some nice new feature to encourage people to perform the upgrade. It's the only thing that might delay the v4 release. For instance, we could rework our styling / theming solution.

[ryancogswell]

For our users (which are almost all corporate users, but from a large number of different companies) over the last 6 months, IE 11 is still the most popular browser.

• 47% IE 11
• 35% Chrome
• 6% Edge
• 6% Safari
• 3% Firefox

It has only been very recently that we have been able to drop support for IE 8-10.

I would like to at least see Chrome clearly eclipse IE 11 usage within corporate environments before dropping support for it.

For comparison, in the 6 months ending a year ago we had 51% IE 11 and 31% Chrome.

[GitTom]

Here's a blog post on the Microsoft tech site by one of their 'cybersecurity' experts (posted a couple days ago)...

The perils of using Internet Explorer as your default browser [microsoft.com]

It reminds people that IE should only be used for compatibility with legacy apps. For that purpose it will be around forever, but those apps are not relevant to this discussion.

And I have found that user who have IE for legacy apps and Chrome for everything else need reminding to switch back to Chrome - they get into IE for some internal apps that require it and forget (or don't know to) switch back.

@ryancogswell That is not to question the importance of your users (or the relevance of your opinion given that you contribute to material-ui and I don't) but stats from an individual vendor/company/user don't really serve the purpose that stats are meant to. Someone could chime in and tell us that their users were almost 100% Chrome - these numbers all have to be placed within a larger context. IE is a small part of the market and with MS actively warning people away from it and other apps dropping support for it I think that the percentage of users who only have IE will be tiny by the time products based on the next version of material-ui are actually in front of them.

[ryancogswell]

@GitTom So far, my contributions have been pretty trivial, so I wouldn't put too much weight on my "contributor" label. I understand that my numbers are not representative of the internet as a whole, but the source of the data for the chart says "18% are corporate sites" and I think my data may be closer to representing more typical corporate browser usage. At the very least, typical corporate IE 11 usage is going to be way more than the 5% in the chart. Ending support for IE 11 could be a showstopper for a whole class of apps that deal primarily with corporate customers and need to avoid the headaches of not supporting the default browser of many of the users.

[eps1lon]

these numbers all have to be placed within a larger context.

I disagree with that. For me the "global usage" argument is incomplete. You have to consider other dimensions here e.g. demographics of your app. It may look fine to loose 5% of customers but are you ok with loosing 90% of elderly people or corporate users? What amount of money spend these 5% on your product? It is not obvious that 5% of your users = 5% of your app value.

All of these things need to be examined on a per app basis. I'm not sure we should make that choice. 1% of our bundle for 5% may be OK. 5% of the bundle for 5% of our users may be not.

Maybe we can extract some of those fixes into a separate package that applies polyfills/(monkey)patches to our components. Then app devs need to explicitly decide if they want to support IE 11 or not.

For example we have some components where we have to write different code because Array.prototype.find is not supported in IE 11. We might as well suggest a polyfill here. It makes no difference whether we write that code down explicitly or have it in the bundle implicitly via polyfill. One could argue that the latter one is better because it helps code de-duplication and reduces the risk of bugs in your custom code.

[ryancogswell]

I certainly have no problem with requiring polyfills for those of us who still need to support IE 11. Our app already has quite a few (including find).

[oliviertassinari]

https://twitter.com/jamiebuilds/status/1022568918949408768?s=19

[eps1lon]

twitter.com/jamiebuilds/status/1022568918949408768?s=19

Sure code transforms is definitely an argument. We can't provide an easy solution via polyfill. However we do currently have an /es build that targets the latest es spec. It's a more advanced optimization but I'm happy with that solution. I want to revisit that build for v4 anyway and that would be a good opportunity to extend the docs for that build.

[klis87]

@oliviertassinari does that mean that it is possible that JSS won't be required anymore in the future? Asking because I prefer css-modules for styling and the only advantage I can see JSS has is that it allows theme changes at runtime, but with css variables you could achieve exactly the same.

(I know I can use css modules now, but JSS is still required anyway for built-in styles)

[oliviertassinari]

@klis87 We have an ongoing effort to minimize the styling solution overhead. We will invest time on the problem.

[nperichSYKES]

Just wanted to chime in that we also only recently dropped IE8 and will likely be supporting IE11 for quite a while.

If you've never worked in an enterprise environment, it might be easy to miss how, unlike every other browser, global usage stats don't really tell an accurate story regarding IE. Enterprise computers might take years or even decades to upgrade, users might not be able to install their own programs so have no possibility of seeking an alternative, and Microsoft currently doesn't offer a browser for even slightly older OSes like Windows 8 (this is supposed be rectified with the Edge rebuild).

More importantly, it's worth noting that even if actual usage numbers of your app are low not just globally but _even in enterprises_, the fact that salespeople can say IE11 is supported is often a requirement for making the sale. And that will probably remain true long after global IE11 usage drops below 1%.

It's also worth remembering that for many people, these enterprise customers are exactly where the money is.

Obviously I understand IE11 support is annoying...that's why I use something like MUI! :) Polyfills of course are easy to add and already being used on our apps, so if using those help make mui easier to work on go for it! Or if there was a package like '@material-ui/iehacks' to import. If it's really an issue for some reason, maybe some widgets don't get updates and the last supported version is frozen at '@material-ui/ie/Dialog` or something.

Thanks for your work on MUI! I appreciate the great tool. Also, worst case we can just keep using an old version of MUI so it's not the end of the world if the benefits of dropping IE are really actually worth it.

[oliviertassinari]

@nperichSYKES Thank you for the feedback. We will take it into account.

[eps1lon]

One thing to consider about dropping IE11 support is that it would disproportionally target screen reader users. While global usage might be < 2% it is around 23% for screen reader users according to https://webaim.org/projects/screenreadersurvey7/#primary. Usage is declining there as well but still way higher compared to global stats. This is an example to what I was referring to in https://github.com/mui-org/material-ui/issues/14420#issuecomment-463106939: Global usage stats are not the full picture and might even be misleading.

I'm more and more leaning towards creating new bundle that targets evergreen browsers. IE11 support remains the same but a slimmer bundle is available (could be used with module/nomodule approach) which means IE11 support is opt-out.

[GitTom]

Am I missing something or is that data from 2017?

[eps1lon]

@GitTom I'm not aware of a more recent study though results for 2019 are scheduled to be released this month: https://webaim.org/projects/screenreadersurvey8/

[eps1lon]

Newest results are in: https://webaim.org/projects/screenreadersurvey8/#browsercombos

Key takeaways:

• primary screen reader is used with IE 11 for 11% of the respondents
• most of these use it with JAWS

It seems very likely to me that this is also closer to how corporate IE 11 usage looks like since they are more likely to provide a paid screen reader to their employees and software updates in a corporate/public sector environment can take a lot longer.

I would re-purpose our /es build to act as a "module" build (targets evergreen browsers) and the default build to act as a "nomodule" build at least as long as react itself supports IE 11. module and nomodule builds explained

[oliviertassinari]

@eps1lon If I understand correctly, the advantage of a re-purpose of the /es folder is to remove the need for a Babel handling of node_modules to target "module" browsers?

I think that it would be interesting to have a table that shows the bundle size necessary to target the IE11 platform (our current default distribution), the "module" browsers (proposal) and the size of the current /es folder. It has the potential to be a good tradeoff.

I like the idea of supporting IE 11 as long as React does.

[eps1lon]

No just remove /es since I don't think it serves a particular purpose other than being the source for a module build. We would provide this out of the box. Transpiling the /es build down targetting evergreen browser should add little overhead.

[oliviertassinari]

I'm sorry, I don't understand the whole proposal. We would rename the /es folder to something like /modules and target older browsers? Sounds fair.

Should we quantify this limited overhead? I don't expect it to be important either, but it might be worth double-checking.

[ryancogswell]

Here's an update on the stats I see for our app. Our app is used almost exclusively within corporate environments. Below is the breakdown of our customers' browser usage in the last 6 months:

• 44% Chrome (40% Windows, 2.6% Mac, 1% Android)
• 41% IE 11
• 7% Edge
• 5% Safari
• 2% Firefox

This is the first time that Chrome has topped IE 11 in our stats, but the IE 11 users still account for a significant percentage of users over the last 6 months from over 200 different companies.

The idea of supporting IE 11 as long as React supports it sounds nice, but I suspect this will not be practical. React still supports IE 9 and 10 with polyfills. It could be several years before they drop IE 11 support.

A more realistic goal may be to support IE 11 at least 6 months to a year beyond the official release (as opposed to preview/beta releases) of Chromium-based Edge. This would mean for sure supporting it for version 5, but perhaps not for version 6.

As long as it doesn't happen too soon (i.e. not in the next year), I would actually be thankful for Material-UI ending IE 11 support since it would give us a strong rationale for ending our own IE 11 support and the maintenance/testing headaches that accompany it.

---

UPDATE Chromium-based Edge was released on January 15, 2020. With that release, there is a non-IE Microsoft browser available for older Windows versions (e.g. Edge can now be installed on Windows 7). Between Sept 30, 2019 (when I first posted this comment) and Feb 10, 2020, our customers' IE 11 usage for the previous 6 months has dropped from 41% to 36%.

[nspaeth]

Many comments here are arguing in favor of keeping IE11 in order to maintain support for business, so I'd like to offer up a counter perspective.

Draconian/underfunded/lazy IT departments are enabled by so many libraries bending over backwards to support them, for free. If, instead, libraries started dropping support, these IT departments would face increasing pressure to update their networks. Additionally, by dropping support, libraries transfer that burden to those IT departments, and removes the overhead from all of the developers who do not care about them.

Chrome, and especially Firefox, support older operating systems pretty well, so these IT policies are decreasingly excusable, especially from a security perspective.

I am more sensitive to the screen-reader demographic, as this group is often cash-constrained, and has a more difficult time making this switch. However, as shown earlier in the thread, NVDA usage is rising fast (which is free), and IE11 usage in this demographic is falling fast.

There is an additional, so-far unspoken for demographic that have needs in opposition to IE11 support: the computing-resource constrained. E.g., users that may have a newer (but low-end) device supporting modern browsers, but with major bandwidth, processing, or memory constraints. Supporting IE11 means keeping in polyfills and other inferior implementations to their detriment when browser native implementations may be much more CPU or memory efficient. I suspect that, for many more developers, this is a bigger demographic than the previous two combined, and is a similarly important equal-access demographic as screen-reader users - who may be simultaneously in this demographic as well.

With that in mind, at what point it is reasonable to expect users to meet developers halfway? Secondly, what is reasonable for library-contributors to maintain vs library-consumers who target the out-of-date IT department demographic?
Perhaps a more broad question for this issue would be: What criteria should the library have for supporting, or dropping support for a platform? E.g., "Support all browsers with at least x% global usage AND y% screen reader usage".

[eps1lon]

If, instead, libraries started dropping support, these IT departments would face increasing pressure to update their networks.

There are actual people using the software provided by the IT department. Non-tech people don't want to switch to another browser. They oftentimes don't even know what a browser is. They just want access to the internet.

That being said we'll probably make "modern bundles" the default in v5 and ship a legacy bundle with it. I don't think we will change our IE 11 support model beyond that.

[oliviertassinari]

There is a side of the story that we haven't heard of much: the Chinese market. I have heard that they have a stronger IE and UC browser usage. Ant Design in v4 (the next version that will soon be stable) drops IE 9 and IE 10 support.

[mbrookes]

Draconian/underfunded/lazy IT departments are enabled by so many libraries bending over backwards to support them, for free. If, instead, libraries started dropping support, these IT departments would face increasing pressure to update their networks.

You might be missing that there is an intermediary here – the software developers who are dependent on libraries such as Material-UI, but whose customer are the afore-mentioned IE11 using monsters (more on that later). If one of the barriers to sale is "must support IE11", then not having IE11 support is business limiting at best. Who we are supporting is no IT departments stuck in the dark ages, but developers who have committed to Material-UI, yet have customers who are, for whatever reason, committed to IE11.

So, why don't these draconian/underfunded/lazy IT departments stop mandating IE11 / find the money to upgrade to Windows 10 / get off their lazy backsides and get on with it?

Because like all things, it isn't quite that simple.

Let's start with this premise: You're a large enterprise with thousands, or tens of thousand of employees who collectively use numerous web based applications and portals – proprietary, third party, and SaaS. Oh, and you've already upgraded to Windows 10 (and everything needed to support it).

Unfortunately the desktop team doesn't get to control the choice of applications, nor their development or replacement cycles; and the historical data that they contain can't just be thrown away for business, legal, or regulatory compliance reasons. Some of these applications only work with IE11. Sucks to be you.

So what to do? Well you don't want to confuse users with two browsers, so, as long as the remaining applications support IE11, that's the default browser. (It's what users are used to anyway. Internet? The the big blue "e" with a swoosh, right?)

So with that in mind, if the business needs a new application, it had better support IE11.

Eventually a business need manifests itself for which the preferred solution only supports modern browsers. Yay! But now we have to educate users that Edge is for the new shiny, IE11 for the old cruddy, (and use whichever you prefer for the rest).

At some point, the number of applications that _need_ a modern browser outweigh those that still _need_ IE11. The scales have tipped, but IE11 lives on. And some of those pesky users have muscle memory like it's Arnie on steroids.

Some day, those legacy IE11 lovin' applications will all finally go away. Until then...

cc @ryancogswell

[GitTom]

There will, of course, be some shops that keep using IE11 for many years to come. I assume that the solution for developers that want to cater to them is to use the last version of MUI that supports IE11 - the existence of those customers can't mean that IE11 support continues to complicate MUI for all those years.

It's just a matter of when, and I would think that, now that Microsoft has sorted out their browser strategy and released the new Edge - and are pushing it like crazy - they will crank up their efforts to move customers off IE11. So there would be rather few situation where a developer would begin development on a new app targeting IE11.

[mbrookes]

@GitTom We can hope! :D

[ryancogswell]

Who we are supporting is not IT departments stuck in the dark ages, but developers who have committed to Material-UI, yet have customers who are, for whatever reason, committed to IE11.

@mbrookes This is definitely the category that our company falls in. Our customers are primarily Fortune 500 companies many of which have internal applications that don't work on modern browsers. On the flip side, many of them now also have internal applications that require modern browsers, so many of their employees are used to switching between two browsers even if they don't really understand what a browser is. Also our IE 11 numbers are finally dropping at a rate that is noticeable from month to month (about a 1-2% drop per month) and I expect this rate of decline to increase as the year progresses. Once our IE 11 usage drops below 10% (which I suspect -- or at least hope -- will happen by the end of 2020), I think we'll be fairly comfortable forcing clients to use a different browser.

[PaulACoroneos]

We have many customers who still use ie11. The number is low but sizeable enough to where we would have significant impact. I would hope that the team continues to support ie11 for the foreseeable future. Thanks for your hard work.

[mbrookes]

@PaulACoroneos When it comes to that stage, are you happy continuing using the last (unsupported) version that works with IE11, or is Hilton willing to pay for long term support? (Not a ransom note, just a practical question based on the reality of us supporting IE11 beyond what is reasonable.)

[PaulACoroneos]

@mbrookes Not taken that way at all. I appreciate the work you and the team do a lot. To be honest adoption is currently low. So most likely we would seek out an alternative.

[ivanjeremic]

I dropped support today because my customers are mostly developers, but I need to say that nothing has changed in 2020, larger companies still only use IE11 (I can only speak for here in Europe). I will never understand how tech blind people in these big companies can be.

[joshwooding]

It's interesting I've been questioning this lately (well since the new Edge has come out).

Well.. mainly brought on by the insanely invasion release (https://www.theverge.com/21310611/microsoft-edge-browser-forced-update-chromium-editorial) and when I found that IE11 doesn't support active-ariadescendant without some workarounds :( (https://github.com/mui-org/material-ui/pull/21695)

I fully understand that quite a lot of people still use IE, and I suspect that number will drop significantly as other people have suggested in the near future. Probably by the time that v5 comes out 😋 But my opinion now (1 year 5 months later - oh how the time flies) is that dropping IE would be acceptable now. I would even say dropping it for v5 would be fine. I promise I haven't been brainwashed by our new chromium overlord 😉.

Another way to think of it is - how many companies are building sites in new technologies that can only be used in IE? I would suspect close to none in 2020. The new edge even has an 'automatic' IE mode so something using Material-UI would use chromium and an IE-only site would use the old Trident MSHTML engine - even then I would expect employees are getting used to switching browsers now when using different sites.

I'm also curious to see if the pandemic has affected IE's market share. But I wonder if now is the time?

Either way, I also welcome the new IE.

[ryancogswell]

@joshwooding Since my last update in February, my app's IE usage has dropped from 36% to 26%. We are also introducing new functionality in our app that leverages a library that doesn't support IE, so in a couple months we are already going to be forcing one segment of our clients (who want the new functionality) to not use IE.

Given that v5 is still several months out, I'd be comfortable with IE support being dropped in v5 and I think my company's customers are close to the most extreme case as far as IE usage.

[oliviertassinari]

We have decided to not support IE 11 when starting the development of the new Data Grid component with @dtassone a couple of weeks ago.

[ivanjeremic]

Bootstrap has dropped now support for IE in v5 I think it is time to get rid of it in a new polished version!

[nperichSYKES]

Just another data point. My app, which has both public web B2C and enterprise B2B customers, is currently at 13% users on IE11 (more than Safari and Firefox combined). This is fairly stable. There's zero possibility we will be able to drop support in the next year. Beyond that, we shall see how effective Microsoft's update program actually is. We don't really have any leverage to force clients to update...supporting IE11 is still just what you have to do for enterprise contracts if you can't be picky.

I certainly don't believe new components need to support IE11. It would be nice if current components in 5.0 supported IE11, but the fact is MUI works great right now and there's no reason we can't just keep using v4.

But I do hope that an IE version of MUI continues to get any critical bug fixes (insofar as is even needed), perhaps just in a mostly frozen 4.x release that sits in a material-ui-ie/package or material-ui/ie/package location.

[oliviertassinari]

The market share of IE in the initial issue's description:

A continuation of the graph, 20 months later:

[yordis]

Opening the door for green-browser only is something I would support nowadays.

Personally, I think Mui@v4 has enough value for most people using it in an enterprise environment (that are for the most part where those stats comes from, for the most part).

I support dropping support for IE, and only support green-browsers.

[balazsorban44]

https://www.theverge.com/2020/8/17/21372487/microsoft-internet-explorer-11-support-end-365-legacy-edge

[oliviertassinari]

We are progressively treating IE11 as a second-class citizen, there are a couple of examples in the codebase:

• OutlinedInput no rounded border
• https://github.com/mui-org/material-ui/blob/661adf79d817ae6ce9514febb7ba4337caf774cd/packages/material-ui/src/useAutocomplete/useAutocomplete.js#L6
• Drop IE11 wobbly workaround #22873
• Force polyfills on IE11: #22814

[mbrookes]

We should probably document these all on one place for v5. (A section in the upgrade guide?)

Adding to the list: ImageList v5 now needs a poly-fill for object-fit for IE11 support.

[SassNinja]

@oliviertassinari is it safe to rely on MUI v5 still supporting IE11 (or rather be at least polyfillable)?

I've read this long discussion and it seems so. However I'd like some confirmation from a member because we're currently starting a large project and would like to use v5 if it won't drop IE support (unfortunately we still have many IE customers)

[oliviertassinari]

@SassNinja Until this issue is closed, we still support IE11. The last release of v5 supports it, e.g. #22940, the most likely path is that we drop IE11 in v6. However, we treat it as a second-class citizen.

There are some components that don't support it. DataGrid doesn't, ImageList doesn't (at least we didn't look if the outdated CSS grid implementation of IE11 could be support), Grid (might not in the future as we explore a CSS Grid implementation), etc.

[eps1lon]

The only special casing we have planned for IE 11 that it'll become opt-in (see legacy bundle). With regards to "support" we don't treat it any different to other browsers. The priority of a browser-specific bug is always proportional to its usage and severity. This effectively translates to "IE11 is a second-class citizen".