[material-ui] Update browser supports in v6

[oliviertassinari]

Summary

We plan to release Material UI and MUI System to v6. It's a great opportunity to update https://mui.com/material-ui/getting-started/supported-platforms/#browser.

To do

• By dropping support for Safari 12.5 browser we can remove the outdated babel proposal plugins to minimize the bundle size. We tried in [core] Remove outdated babel proposal plugins #36795 but had to revert it: Revert "[core] Remove outdated babel proposal plugins (#36795)" #37331. (Done in [core] Remove outdated Babel plugins #42140)
• Drop Safari 12 and 13 support to allow https://caniuse.com/flexbox-gap. (Done in [core] Update browser support versions #41568)
• With the update of the default browsers, we can likely remove all of this normalization logic:

  material-ui/packages/mui-utils/src/scrollLeft.js

  Line 23 in b3548fa

  export function detectScrollType() {

• [material-ui][mui-system] Completely remove IE 11 support in v6 #14420
• Migration guide: #42194
• Drop Safari < 14 support [mui-material][mui-system] Drop support for Safari < 14 #42459

Motivation

Remove outdated code => lighter bundle => better UX.

Off-topic

@DiegoAndai I wonder in #30660, did we move all of the checkboxes to dedicated GitHub issues?

For example, it couldn't find this issue. There might be 10 new GitHub issues to create.

Search keywords: update browser support

[DiegoAndai]

Hey, @oliviertassinari! This is considered for v6 👍🏼. I don't think we need this issue as an umbrella, we should rather have:

• One for IE ([material-ui][mui-system] Completely remove IE 11 support in v6 #14420, already included in the v6 milestone)
• One for Safari
• One for this idea: "With the update of the default browsers, we can likely remove all of this normalization logic... (link)"

Do you agree? I can create the missing ones

The v6 brainstorm list idea was moved here and linked in the #30660 issue. Some of these already have github issues that are included in the v6 milestone (for example #30671, #32546) but not all yet. This was done to make the #30660 issue more concise.

[oliviertassinari]

I don't think we need this issue as an umbrella, we should rather have

@DiegoAndai It can make sense but I think we also need to know the full picture of v6 browser support. I needed this issue to know if my comment in #40258 (comment) is right or wrong. We can't make a tradeoff on the supported versions with each browser in isolation, it's the whole that matters since developers ship the same JavaScript file for all their clients.

The v6 brainstorm list idea was moved here and linked in the #30660 issue. Some of these already have github issues that are included in the v6 milestone (for example #30671, #32546) but not all yet.

Alright, let's get this list to GitHub, the sooner the better. I created a new one: #40960.

[oliviertassinari]

A requirement: we probably want to make sure we can use flex gap, e.g. https://github.com/mui/mui-x/pull/11529/files#diff-47ba3ae9e7d214448776b30bfed8130d9cae1a144ee7a768f1ba771f75386d94R67 with Material UI v6.

[oliviertassinari]

Depending on the browsers we drop support for, we might no longer need the @babel/runtime transpilation util.

For example #41071 that needs it for the spread operator for IE 11 partial support https://caniuse.com/?search=spread%20operator

[oliviertassinari]

It would be great to define right now what's going to be Material UI v6 browser support so that MUI X v7 @flaviendelangle @cherniavskii @DiegoAndai can make the corresponding breaking changes, we would eventually be in sync in the BC slots of 2024.

So far, I'm only aware of:

• IE 11 will be removed
• CSS flex gap -> we need to bump to Firefox 78, Chrome 91, Safari 14.1

The main difference would be the Safari bump from 12.5, released around 2019 to 14.1 released in Apr 29, 2021.

But is this wise? I guess Safari is the bottleneck, so it's about checking the release notes of Safari: https://webkit.org/blog/category/news/ to find more constraining limits 🤔:

• Safari 17.0: CSS popup, more CSS display: contents fixes,
• Safari 16.5: CSS selector nesting,
• Safari 16.4: CSS :dir(ltr), Media Queries level 4, Custom CSS properties, Fix outline + border radius
• Safari 16.2: CSS color-mix
• Safari 16.0: CSS container query, CSS Subgrid, CSS has(:target), CSS display: contents
• Safari 15.4: CSS has support, CSS svw unit, CSS :focus-visible.
• Safari 15.0: CSS aspect ratio

Looking at the use of Safari out there, it seems that we could go up to have Safari 16.0 as the minimum version (released Sep 12, 2022), per https://caniuse.com/css-container-queries, the % of browsers left on the side looks within what's acceptable.

Should we go higher? Unclear. color-mix looks pretty cool to significantly reduce the number of CSS variables, but maybe for Material UI v7.

[DiegoAndai]

We'll need color-mix for Material Design 3 (Material UI v7, Q4 2024). We had to use it already in material-next, so we must update to at least 16.2 by v7. Would it be better to stop at 14.1 in v6 or go straight for 16.2? Does MUI X have any requirements for the Safari version?

I added this topic for the next Material UI meeting, which is next Tuesday 27; let me know if we need an answer sooner than that.

Can I Use usage table

[oliviertassinari]

Material UI v7, Q4 2024

@DiegoAndai Today, Safari v16.2 feels a bit borderline, 3% of global usage would be missing:

but 2024 Q4, this sounds ok.

Maybe it could be:

• Material UI v6: Safari v15.4 to get :focus-visible
• Material UI v7: Safari v16.2 to get color-mix

[flaviendelangle]

Does MUI X have any requirements for the Safari version?

We have one :focus-visible that is already in production 😬

[DiegoAndai]

Maybe it could be:

• Material UI v6: Safari v15.4 to get :focus-visible
• Material UI v7: Safari v16.2 to get color-mix

Sounds good to me 👍🏼

[DiegoAndai]

We discussed with the Core styled team today, and we settled on Safari v15.4 for v6 👍🏼

For v7, Safari v16.2 is the initial idea, but we'll have to discuss further with the Base UI team when work for that version starts.

[cherniavskii]

BTW, we have a .browserslistrc file in the repo, is it actually being used?
Should we bump the browsers version there?

[o-alexandrov]

imho, 15.4 is a bit too radical for v6, given both latest ReactNative & Expo have iOS 13 as the minimum.
The idea to use mui'd be harder to sell to clients within web-based apps react-native-webview.

Targeting iOS 14 for V6 makes more sense for the case above, as the to-be-released Expo v51 probably would start to target iOS 14 also.

---

EDIT: if MUI starts targeting iOS 15.4 as the minimum, it'd be great to have a list of specific iOS >=15.4 features you plan to use, so any mui's user could attempt to polyfill them.

[o-alexandrov]

We'll need color-mix for Material Design 3 (Material UI v7, Q4 2024). We had to use it already in material-next, so we must update to at least 16.2 by v7. Would it be better to stop at 14.1 in v6 or go straight for 16.2? Does MUI X have any requirements for the Safari version?

I added this topic for the next Material UI meeting, which is next Tuesday 27; let me know if we need an answer sooner than that.

Can I Use usage table

@DiegoAndai you don’t need color-mix() (iOS >=16.2). PigmentCSS is build-time CSS. You can use Google’s material-color-utilities or other complex build-time color transformations to invoke color-mix() alternative at build-time.

Moreover, even if color-mix was available in all browsers, all CSS calculations are slower than build-time calculations that would result in literals, so there’s a minor side benefit of a build-time color calculation

[DiegoAndai]

Hey @o-alexandrov, thanks for reaching out and making us aware of the ReactNative compatibility. I'll discuss v6 and v7's safari version with the team once more taking your comment into consideration.

The idea to use mui'd be harder to sell to clients within web-based apps react-native-webview.

Have you been using this? I'm curious about the results 😊

[o-alexandrov]

@DiegoAndai yes, I am currently using react-native-webview in a couple of active projects and plan to continue creating web-based react native apps.
You can check iOS or Android app (or anime.club website to confirm the app and the website are identical), if you want to feel performance-wise how a web-based MaterialUI (thank you) based app works within react-native.

[siriwatknp]

I think we could target Safari 14 as a minimum for v6 because the main goal is to add support for Pigment CSS. I don't think we will change any of the CSS implementations like gap, and :focus-visible.

In v7, we could bump to 15.4 when we revamp the CSS implementation.

[DiegoAndai]

@o-alexandrov I see that Expo SDK 51 has been in beta since yesterday (https://expo.dev/changelog/2024/04-24-sdk-51-beta). It says that this will last a week. Does that mean it will be released as stable next week?

I couldn't find anything on their GitHub page indicating that they are upgrading to iOS 14 on SDK 51. Do you have a reason to believe they will target this version?

As @siriwatknp mentioned, from the core team, we don't have a strong argument for going higher than 14 for v6.

@cherniavskii @flaviendelangle @oliviertassinari, what do you think about this discussion? Would you be on board with being more cautious: Safari 14 for v6 (target June 2024) and Safari 15.4 for v7 (target March 2025)?

[o-alexandrov]

@DiegoAndai I thought Expo would start to target iOS 14, but Expo keeps the target at iOS 13.4. I just manually confirmed w/ [email protected] by running expo prebuild to generate ios directory and it's still 13.4 in the Podfile.

Does that mean it will be released as stable next week?

I guess they rush it due to iOS Privacy manifest config field new requirement set by Apple by May 1st, 2024.
You can see it's part of some of the expo plugins latest versions which also contain other breaking changes; for example expo-system-ui v3 changelog

Expo has a discord server, you can ask them directly

[DiegoAndai]

Hey @o-alexandrov! We've discussed it once more, and the final decision is to go to safari >=15.4 for v6, as per the original plan. This keeps us synced with MUI X and covers more than 90% of the audience, and there's not much gain in supporting 14.0 (+1% coverage).

We will need 15.4 for refactoring Material UI on top of Base UI; so far, the only requirement is the dialog element.

I'm sorry to say we won't adhere to React Native / Expo's supported versions, as that seems like too much of a constraint. I hope this is not much of an inconvenience, and as always if you need help with anything feel free to reach out!

[o-alexandrov]

@DiegoAndai could you please consider to create a notice of the iOS 14+ features you use? MUI users would then know what to polyfill

[DiegoAndai]

@o-alexandrov at the moment, the dialog element is the only candidate, but that's to be defined and won't happen immediately. It might not even happen soon.

It might be difficult for us to keep track of features that need to be polyfilled on versions we no longer support. Removing support for certain versions keeps the scope manageable, which is not possible if we need to track every feature that might require polyfills.

What I think might work better is that if anyone finds something that needs to be polyfilled in the future, they can open an issue from which we can create guides on how to polyfill that particular feature.

[o-alexandrov]

@DiegoAndai while creation of guides would ease the work for the user, even keeping a list of iOS 14+ features would already simplify the work for anyone who needs to polyfill.

I'd be happy to see such list in a little paragraph where the breaking changes are mentioned:

• https://next.mui.com/material-ui/migration/migration-v5/#breaking-changes

[DiegoAndai]

I'd be happy to see such list in a little paragraph where the breaking changes are mentioned

That makes sense 👍🏼 I'll look into it

[DiegoAndai]

All tasks completed