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

[jbojcic1]

@eps1lon how do I use the legacy bundle in the v5?

I've found this in the docs https://next.material-ui.com/guides/minimizing-bundle-size/#legacy-bundle

but if I import stuff from '@material-ui/core/legacy' the typescript is complaining: TS7016: Could not find a declaration file for module '@material-ui/core/legacy'.

[eps1lon]

By using resolve aliases in your bundler (e.g. resolve.alias in webpack) not by importing from that folder. We should add a section to the docs explaining that

[jbojcic1]

@eps1lon I was able to figure it out and make it work with aliases but there is issue with rifm datepicker dependency if you use @material-ui/lab because it's not built for es5. I worked around it by copying rifm code so it's transpiled by my babel and then aliasing it too. So something like:

resolve: {
    ...,
    alias: {
      '@material-ui/core': '@material-ui/core/legacy',
      '@material-ui/styles': '@material-ui/styles/legacy',
      '@material-ui/lab': '@material-ui/lab/legacy',
      '@material-ui/styled-engine': '@material-ui/styled-engine/legacy',
      '@material-ui/system': '@material-ui/system/legacy',
      '@material-ui/unstyled': '@material-ui/unstyled/legacy',
      '@material-ui/utils': '@material-ui/utils/legacy',
      'rifm': path.resolve(__dirname, 'src/custom-rifm.js')
    }
  },

[oliviertassinari]

but there is issue with rifm datepicker dependency

@jbojcic1 https://github.com/realadvisor/rifm/issues/109. However, new components we have introduced since last year (date picker, data grid, and image list) are not supporting IE 11. Next.js is also no longer working in dev mode with IE 11 so it's very hard for us to work on these issues.

[jbojcic1]

I see. Thx for explanation. For this case I actually just need to support very old chrome (39) which needs es5 and the date picker seems to be working fine with the workaround I explained above so I am good.

[oliviertassinari]

I'm moving this as an attempt for v5. We have lost the environment to work on IE 11 bugs. Codesandbox doesn't any longer support it. Next.js has numerous issues with it https://github.com/vercel/next.js/issues/13231 that prevents us fixing issues.

[eps1lon]

I'm moving this as an attempt for v5.

Why was this not discussed? It's a bit problematic to move this into v5 when we're weeks away from the beta.

[oliviertassinari]

@eps1lon I meant as an "attempt", so we can create a new discussion :). The last time we talk about it was August 4th 2020, about 6 months ago. We had this as a takeaway in the notes:

• Different bundles, for showing better bundle size defaults -> done 👌
• Wait for more maturity on v5 before making a call -> maybe now is a better time?

I think that v5-beta is 2-3 months away (assuming we want to do the 50 BCs listed, and we will have Marja + a new member to help most faster). v5 stable might be, ~6 months away to give time to fix bugs/regressions?

[eps1lon]

@eps1lon I meant as an "attempt", so we can create a new discussion :).

But you did already change the milestone. I don't understand what you consider a discussion if you already presuppose the outcome.

To clarify: You have to make an argument why this should be changed to v5. Not change it to v5 and then expect a discussion to start. That's really weird to me.

[oliviertassinari]

@eps1lon I have tried to develop a new argument for dropping support of IE 11 in https://github.com/mui-org/material-ui/issues/14420#issuecomment-792070436. Our development environment do no longer allows us to makes fixes, both codesandbox and Next.js have numerous issues with it that we would need to fix first (especially Next.js currently makes it hard in dev mode).

The previous arguments for dropping IE 11 was around the opportunity cost. Is it worth the effort? DataGrid, Pickers, ImageList, already said no.

[oliviertassinari]

In https://github.com/satya164/react-simple-code-editor/pull/81#issuecomment-782870990 @mbrookes seemed to be in favor of dropping IE 11 entirely. It was based on the fact that IE 11 is End-of-Support in eight months. This wouldn't be too far away from the release date of v5 stable.

As far as I remember, the one advantage of keeping IE 11 was for its screen reader audience https://github.com/mui-org/material-ui/issues/14420#issuecomment-528756542. 23.3% in 2017. The latest survey from 2019 is at 10.9% of IE 11 adoption. But what about 2021, two years later?

[mbrookes]

@mbrookes seemed to be in favor of dropping IE 11 entirely

Please don't put words in my mouth. A code editor, and by extension the developer documentation of Material-UI, is not the same as Material-UI itself. Also:

1. A developer would have to be using IE11 as their primary development browser to be affected by that change if used in the MUI docs.
2. That change is intended as "progressive degradation" – no syntax highlighting in IE11; not breaking it entirely.

That said, regarding support of IE11 in MU v5, some of the same arguments do still apply: v4 doesn't suddenly stop working just because v5 is released. Anyone that needs to support a legacy unsupported browser can use a legacy unsupported library.

That doesn't mean we should rip out support for IE11 in v5 just because; but I don't think we should put any effort into supporting it either.

What does matter though is not having sudden unplanned changes in strategy, as @eps1lon has already said.

[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 https://github.com/mui-org/material-ui/issues/14420#issuecomment-792070436, what triggered it? It was meant as a solution for: #25222.

[oliviertassinari]

I have made an attempt implementation of https://github.com/mui-org/material-ui/issues/14420#issuecomment-792276203 in https://github.com/mui-org/material-ui/pull/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 https://github.com/mui/material-ui/issues/30660."

[oliviertassinari]

Ant Design did it in https://github.com/ant-design/ant-design/issues/33862.

[mbrookes]

While tackling https://github.com/mui/material-ui/pull/42283#issuecomment-2144043088 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.

https://github.com/mui/material-ui/pull/42283#issuecomment-2146010216 for a list of the Material UI specific ones.

[DiegoAndai]

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