Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[material-ui] Update browser supports in v6 #40958

Open
3 of 5 tasks
oliviertassinari opened this issue Feb 5, 2024 · 23 comments
Open
3 of 5 tasks

[material-ui] Update browser supports in v6 #40958

oliviertassinari opened this issue Feb 5, 2024 · 23 comments
Assignees
Labels

Comments

@oliviertassinari
Copy link
Member

oliviertassinari commented Feb 5, 2024

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

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

@oliviertassinari oliviertassinari added breaking change package: material-ui Specific to @mui/material status: waiting for maintainer These issues haven't been looked at yet by a maintainer labels Feb 5, 2024
@oliviertassinari oliviertassinari added this to the Material UI: v6 milestone Feb 5, 2024
@oliviertassinari oliviertassinari changed the title Material UI v6: Update browser supports [material-ui] Update browser supports in v6 Feb 5, 2024
@DiegoAndai DiegoAndai self-assigned this Feb 5, 2024
@DiegoAndai
Copy link
Member

DiegoAndai commented Feb 5, 2024

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

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.

@DiegoAndai DiegoAndai removed the status: waiting for maintainer These issues haven't been looked at yet by a maintainer label Feb 5, 2024
@oliviertassinari
Copy link
Member Author

oliviertassinari commented Feb 5, 2024

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
Copy link
Member Author

oliviertassinari commented Feb 7, 2024

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
Copy link
Member Author

oliviertassinari commented Feb 12, 2024

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
Copy link
Member Author

oliviertassinari commented Feb 18, 2024

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.

SCR-20240218-odhq

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
Copy link
Member

DiegoAndai commented Feb 19, 2024

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
Copy link
Member Author

oliviertassinari commented Feb 19, 2024

Material UI v7, Q4 2024

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

SCR-20240219-twxv

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
Copy link
Member

Does MUI X have any requirements for the Safari version?

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

@DiegoAndai
Copy link
Member

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
Copy link
Member

DiegoAndai commented Feb 26, 2024

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
Copy link
Member

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

@o-alexandrov
Copy link

o-alexandrov commented Apr 17, 2024

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
Copy link

o-alexandrov commented Apr 23, 2024

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
Copy link
Member

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
Copy link

o-alexandrov commented Apr 24, 2024

@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
Copy link
Member

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
Copy link
Member

@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
Copy link

o-alexandrov commented Apr 25, 2024

@DiegoAndai I thought Expo would start to target iOS 14, but Expo keeps the target at iOS 13.4. I just manually confirmed w/ expo@51.0.0-preview.4 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
Copy link
Member

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
Copy link

@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
Copy link
Member

DiegoAndai commented May 3, 2024

@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
Copy link

@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:

@DiegoAndai
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: In progress
Development

No branches or pull requests

6 participants