[material-ui][mui-system] Completely remove IE 11 support in v6

[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.

[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 #14420 (comment): 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/

[BrendanMayHRB]

IE11 is still the default browser for all Outlook Web Add-ins for Outlook 2013 as well as volume licenced 2016, and 2019 : https://learn.microsoft.com/en-us/office/dev/add-ins/concepts/browsers-used-by-office-web-add-ins

[ozgur-dogan]

Office 2013 will reach the end of support on April 11, 2023. After this date, support for Office 2013 will end and security updates will no longer be available, per the Fixed Lifecycle Policy. This may increase your organization's exposure to security risks or impact compliance obligations.

[oliviertassinari]

Dropping all logic that covers IE 11 is scheduled for MUI Core v6 #30660.

[BrendanMayHRB]

Office 2013 will reach the end of support on April 11, 2023. After this date, support for Office 2013 will end and security updates will no longer be available, per the Fixed Lifecycle Policy. This may increase your organization's exposure to security risks or impact compliance obligations.

Respectfully I think you missed the point. iE 11 is REQUIRED to use Outlook Web Add-ons for all versions up to and including Outlook 2019 volume licence.

So given the 10 year fixed lifetime policy, Microsoft will require IE11 for all outlook web addins until 2029.

[ozgur-dogan]

Office 2013 will reach the end of support on April 11, 2023. After this date, support for Office 2013 will end and security updates will no longer be available, per the Fixed Lifecycle Policy. This may increase your organization's exposure to security risks or impact compliance obligations.

Respectfully I think you missed the point. iE 11 is REQUIRED to use Outlook Web Add-ons for all versions up to and including Outlook 2019 volume licence.

So given the 10 year fixed lifetime policy, Microsoft will require IE11 for all outlook web addins until 2029.

I didn’t say we should drop support.

[BrendanMayHRB]

according to @oliviertassinari, "Dropping all logic that covers IE 11 is scheduled for MUI Core v6 #30660."

[oliviertassinari]

Ant Design did it in ant-design/ant-design#33862.

[mbrookes]

While tackling #42283 (comment) doesn't remove IE specific code per-se, the use of Array.indexOf('some string') [===|!==] -1 instead of Array.includes was specifically for IE11 support, so I'd consider it a code smell now that we've dropped support for IE11, and I'm not sure I'd consider this issue closed without it.

#42283 (comment) for a list of the Material UI specific ones.

[DiegoAndai]

@mbrookes yes, I'll create an issue for this.