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

[oliviertassinari]

Please don't put words in my mouth.

@mbrookes OK, this makes sense. I have made the logical jump with: 1. if maintainers can't work on the components in dev mode, the components can't be improved on the IE 11 dimension. 2. if developers can't load the documentation with IE 11, developers will seriously doubt that the components work with IE 11. But I guess it doesn't have to be black or white.

[mbrookes]

I have made the logical jump

Neither of which of the supporting arguments for is correct.

[oliviertassinari]

How about the following solution?

We update the documentation in v5 that IE 11 support is partial, that we don't intent to improve it (closing issues and potentially PRs that try to), nor to degrade it (no active effort to remove IE 11 docs or logic). Then in v6, we remove all traces of IE 11.

This would match with reality: we almost can't work on it in dev mode, pickers, data grid, modal, image list, are not supporting it, we have a low to no incentive to improve it. Because it matches reality, this would increase trust.

In the current documentation, it's not really clear if IE 11 is supported. It's not listed in the supported browsers table, https://next.material-ui.com/getting-started/supported-platforms/#browser, but as a legacy build.

Regarding the unplanned change. As far as I know, we never publicly nor internally said that v5 would come with great IE 11 support. Please correct me if I am wrong. The proposal seems to be compatible.

[EugenMayer]

If I may from the perspective of someone who supported IE6, IE7 .. IE11 for decades with the application we offer B2B (which is I guess the concern, the companies). We always have been very conservative with deprecated and removing IE support in the past. We really feel with you when the topic comes up on "how to actually support IE" when there are basically no tools and even running some versions is impossible or debugging them is close to useless.

That said, or maybe even because of that, even we have removed the IE11 support Nov 2020 entirely. We did not go the route that we just dropped it officially but told people "it works as it works, but we won't fix it any longer". This usually does simply not work out well with customers, they just need a clear line, nothing blurry - or they will be unsatisfied and unhappy that "this one datagrid" or "this datepicker" does not work.
This said, we blocked any access with IE11 and tell the user to upgrade - and of course, we started to remove polyfills and all those gazillion hacks one needs for IE11 (or before).

We also utilize Material UI and it has been, for 4.x, one criterion we looked at when we evaluated our new goto UI/UX framework about 2 years ago. Obviously today it is no longer relevant.

What I wanted to share was, that our customers always were very conservative and slow with upgrading anything regarding their browsers. This seems to have changed drastically over the last 3-4 years.

We announced our deprecation of IE11 in early 2020 - not a single "feedback" to this announcement. A reminder in May brought up 1 customer who asked to have more time to finish their work - so we did not upgrade them Nov 2020 but end of Jan 2021. So very easy going and really not expected to be that easy at all. It surprised us.

Now all customers, including all the old ones who stuck with IE6, IE7, IE8 and every other back in the days - all moved. I'm not sure where they all moved, think it depends, some to Edge Chromium, some FF, or Chrome - but it does not really matter to us.

Sharing this to have an additional POV on this really hard topic about a strategic decision.

Written above, we have drawn a clear line, not a blurry one "as is", since our experience was, that this just causes a lot of frustration on the user side. I'm not sure if this aspect can be take over to an OSS UI/UX framework, since you have a huge userbase that 'are non-paying customer' and (I hope and expect) are a lot more understanding than a paying customer "who just has expectations".

Not sure therefore if you can actually take anything from what I have written. I really just feel and understand the struggle and the back and forth of this decision very much.

Great to see this process up in the opening and who it slowly but steady moves. Keep it up, guys!

[eps1lon]

In the current documentation, it's not really clear if IE 11 is supported.

What do you find missing from "If you need to support IE 11, check out our legacy bundle."?

[oliviertassinari]

What do you find missing from "If you need to support IE 11, check out our legacy bundle."?

@eps1lon I was initially confused that it's not listed with the other major browsers in the table. But you are right it's definitely mentioned as available under a separate bundle.

[oliviertassinari]

For people reading the thread and wonder why #14420 (comment), what triggered it? It was meant as a solution for: #25222.

[oliviertassinari]

I have made an attempt implementation of #14420 (comment) in #25262.

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