[docs] Drop IE 11 official support

[iammminzzy]

This is the first step towards #14420. This PR official communicates that IE 11 is no longer supported. This is a breaking change.

More changes will be required to close the issue, but they won't be breaking changes in theory as IE 11 is no longer supported #41611 (comment).

[mui-bot]

Netlify deploy preview

• docs/data/material/components/app-bar/app-bar.md
• docs/data/material/components/cards/cards.md
• docs/data/material/components/lists/lists.md
• docs/data/material/components/progress/progress.md
• docs/data/material/components/slider/slider.md

Bundle size report

No bundle size changes (Toolpad)
No bundle size changes

Generated by 🚫 dangerJS against 98494bd

[ZeeshanTamboli]

@iammminzzy Thank you for the pull request. Apart from the code updates, we should also remove the legacy bundle build, as discussed in #41568 (refer to #41568 (comment)). Additionally, we need to remove ie 11 from the .browserslistrc file. Perhaps we should also update the docs.

[iammminzzy]

@iammminzzy Thank you for the pull request. Apart from the code updates, we should also remove the legacy bundle build, as discussed in #41568 (refer to #41568 (comment)). Additionally, we need to remove ie 11 from the .browserslistrc file. Perhaps we should also update the docs.

Thank you for your advice. Should I push these changes to this PR or can this PR be landed as an incremental improvement, since there are still many more things to handle to remove IE 11 support completely?

[ZeeshanTamboli]

@iammminzzy Thank you for the pull request. Apart from the code updates, we should also remove the legacy bundle build, as discussed in #41568 (refer to #41568 (comment)). Additionally, we need to remove ie 11 from the .browserslistrc file. Perhaps we should also update the docs.

Thank you for your advice. Should I push these changes to this PR or can this PR be landed as an incremental improvement, since there are still many more things to handle to remove IE 11 support completely?

This should be done in a single PR; otherwise, it might remain incomplete if not addressed in separate PRs.

[iammminzzy]

@iammminzzy Thank you for the pull request. Apart from the code updates, we should also remove the legacy bundle build, as discussed in #41568 (refer to #41568 (comment)). Additionally, we need to remove ie 11 from the .browserslistrc file. Perhaps we should also update the docs.

Thank you for your advice. Should I push these changes to this PR or can this PR be landed as an incremental improvement, since there are still many more things to handle to remove IE 11 support completely?

This should be done in a single PR; otherwise, it might remain incomplete if not addressed in separate PRs.

I’m happy to look into how the packages get built, but I feel like a core maintainer would be better positioned to address these things in a follow-up PR

[iammminzzy]

@ZeeshanTamboli I followed the approach in #41568 and removed legacy bundle and updated the docs. Feel free to push any further updates to this PR.

[ZeeshanTamboli]

There were many style-related references but I thought they were riskier to change, so I left those alone.

Could you try to replace them?

There was also

material-ui/packages/mui-material/src/Tabs/Tabs.js

Lines 423 to 425 in 0102a95

	// IE11 support, replace with Number.isNaN
	// eslint-disable-next-line no-restricted-globals
	if (isNaN(indicatorStyle[startIndicator]) || isNaN(indicatorStyle[size])) {

but changing isNaN to Number.isNaN seemed wrong despite what the comment says (I believe typeof indicatorStyle[startIndicator] === 'number' should be used).

Why Number.isNaN seems wrong from typeof number?

Additionally, I wasn't sure if stableSort() was safe to drop because I'm not sure if 2020 browsers are meant to be supported:

material-ui/docs/src/components/showcase/FolderTable.tsx

Lines 48 to 52 in 0102a95

	// Since 2020 all major browsers ensure sort stability with Array.prototype.sort().
	// stableSort() brings sort stability to non-modern browsers (notably IE11). If you
	// only support modern browsers you can replace stableSort(exampleArray, exampleComparator)
	// with exampleArray.slice().sort(exampleComparator)
	function stableSort<T>(array: readonly T[], comparator: (a: T, b: T) => number) {

I believe we can safely remove it. It's also included in a demo, and we are supporting browsers that fully support Array.prototype.sort().

[NMinhNguyen]

@ZeeshanTamboli I’m curious as to why the scope of this PR has to keep increasing, when the author evidently intended to only help clean up some JS references. The original PR that updated browserslist also didn’t try to solve the whole old browser support issue and was landed in an incremental fashion. Surely all these other issues can be addressed in follow-up PRs by a core member?

[ZeeshanTamboli]

@ZeeshanTamboli I’m curious as to why the scope of this PR has to keep increasing, when the author evidently intended to only help clean up some JS references.

@NMinhNguyen I believe we shouldn't remove the old code references until the browser support has been officially removed. If we ship the replaced code without actually removing the browser support, it could lead to potential issues. What's the guarantee that the removal of IE 11 browser will be in the same release as this? We need to ensure that the removal of IE 11 browser support coincides with this change.

The original PR that updated browserslist also didn’t try to solve the whole old browser support issue and was landed in an incremental fashion.

It only updated the supported browsers list because the removal of IE 11 could be done separately. In my opinion, they were not interconnected.

Surely all these other issues can be addressed in follow-up PRs by a core member?

If you want us to handle it, you can close this PR.

[NMinhNguyen]

What's the guarantee that the removal of IE 11 browser will be in the same release as this?

There is a stated goal of removing IE11 support as part of v6, and it's relatively recent that the repo has switched from master to next as the main branch, so I would say that there is more than enough time for this work to be picked up subsequently, without needing to block this contribution.

it could lead to potential issues.

What issues exactly? V6 states that IE11 is no longer supported, so any issues arising from not having polyfills for the native JS APIs that this PR introduces, are expected.

[oliviertassinari]

Surely all these other issues can be addressed in follow-up PRs by a core member?

The smallest possible scope of this PR is to update all docs to not mention IE 11 anymore. It's like a 10 lines removal.

Closing #14420 requires updating all the code. So this could be one or many PRs, whatever is smoother.

[NMinhNguyen]

Surely all these other issues can be addressed in follow-up PRs by a core member?

The smallest possible scope of this PR is to update all docs to not mention IE 11 anymore. It's like a 10 lines removal.

Closing #14420 requires updating all the code. So this could be one or many PRs, whatever is smoother.

Sounds good, I think this PR should definitely have a limited scope and not close the linked issue, merely reference, which is what it did before @ZeeshanTamboli ’s edit.

Let’s split out the JS reference changes into a separate PR that also doesn’t close the linked issue, merely reference.

Finally, once all the IE references are removed (CSS etc.), then the issue can be closed in that PR.

[iammminzzy]

Thanks for your input, everyone!
I have removed all IE references from .md files and reverted all other changes.

Please let me know if this is in a mergeable state now.

[ZeeshanTamboli]

I still don't fully agree with the decision to separate it, but if that's what's been decided, then I'm okay with it. As a community contributor rather than a team member, my suggestions may not carry much weight. Anyway you have already created another PR to drop the code: #41709, so it's fine. 👍

I've identified two other places where we need to remove it:

1. From the stickyHeader prop of the Table component. You can find it here: Table Prop - stickyHeader. Once text is removed from the type definition, remember to run pnpm proptypes && pnpm docs:api to update the Proptypes and API docs.

2. Not directly related to Material UI, but we can also remove it from Joy UI:

   • Table Prop - stickyFooter
   • Table Prop - stickyHeader

[NMinhNguyen]

@ZeeshanTamboli thanks for the pointers, I believe the API docs have now been updated too, so there shouldn't be any remaining references to IE in the v6 docs.

[ZeeshanTamboli]

Looks good to me. Since it is a breaking change, I'd like to have others review it as well before merging.

[Janpot]

👍 I see no problem with splitting this.