Open NawarA opened 2 years ago
It would be a good business model to adopt Material 3 and offer updates to Material 2 under proprietary licenses only. Like Oracle did with Java.
That way everyone will be happy.
lol
It would be a good business model to adopt Material 3 and offer updates to Material 2 under proprietary licenses only. Like Oracle did with Java.
Adopting Material Design v3 is part of our roadmap. However, supporting both Material 2 and Material 3 with the same effort isn't, the sooner we drop Material Design v2, the better.
Here is one possible execution path, with a guessed timeline:
cc @mnajdova for thoughts.
I think that other variations would make sense as we could already do one stable release at step 2, and another major at step 4 🤷♂️
Thank you all for the work on this 🙇🏻 Would it be possible to create a roadmap to show the advancements in adopting Material Design v3? :) I'd really appreciate it.
@oliviertassinari the plan proposed make sense.
- Hire one Design Engineer, to own the work on Material Design. Q2 2023?
- Have the person focus on getting @mui/material-next to move forward, building with Base UI and Material Design v3. Effectively, laying the foundation for Material UI v6. Do as much as possible without the need for breaking changes in Base UI. Q2 2023?
Done, we are starting next month (June) to work actively on this - adding more components to @mui/material-next. We will try to keep the API of the components as close to v5 as possible, unless Material You has different nomenclature.
- Once we need to do breaking changes in Base UI, pause all work on the stable release of MUI Core v5 and move all effort to MUI Core v6. Q4 2023?
Most probably, cannot guarantee on the actual timing, but looks like a good estimation.
- A stable MUI Core v6 release, there we would want RSC support. Q1 2024?
At the earliest yes, for the RSC I am starting to think that it will need to be in a form of opt-in (using some zero runtime CSS-in-JS), and provide a different API for emotion, for e.g. one that doesn't depend on context - I am not sure if it will be possible but it's one option.
Would it be possible to create a roadmap to show the advancements in adopting Material Design v3? :) I'd really appreciate it.
We already added it to the roadmap, this month we will create the definite list of components we want to add this quarter.
I think that other variations would make sense as we could already do one stable release at step 2, and another major at step 4
I would be also curious to hear the community opinion on this. In terms of what would be the preferred upgrade strategy:
In my opinion I would go with option 1, as I weight these two updates equally important (desirable), but I may be wrong in this assumption. Here are some of the related issues: RSC - https://github.com/mui/material-ui/issues/35993, zero-runtime CSS in JS - https://github.com/mui/material-ui/issues/34826, Nextjs 13 app directory support (related to RSC) - https://github.com/mui/material-ui/issues/34905
I'd vote for Option 3 as the styling solution might not be perfect at first and you might want to make changes to it.
I'd prefer option 2. Material You would be the most pressing for me. I'd be especially happy, if the API would remain similar to the current version (of course if patterns are different, API changes would be totally acceptable). The new styling solution would surely be appreciated, but it's not a very pressing matter for me.
Ideally I would say option 1, as I would like to have both on the next release, but it seems that way the aim is Q1 2024 for v6.
So in the case one could be prioritized over the order to have a sooner v6 release I would then choose option 3, as having a zero runtime solution would provide the support for RSC, which I think is a bigger deal. For now I can get Material You components by theme customization.
Ideally I would say option 1, as I would like to have both on the next release, but it seems that way the aim is Q1 2024 for v6.
So in the case one could be prioritized over the order to have a sooner v6 release I would then choose option 3, as having a zero runtime solution would provide the support for RSC, which I think is a bigger deal. For now I can get Material You components by theme customization.
sorry to asking here, but how do you get the Material You in v5? can you share the theme customization?
My vote is option 3 so we can get a styling solution fully compatible with Next.js's App Router and RSC as soon as possible, unless we think Next.js and React will figure out soon how to make CSS-In-JS work with RSC (doubtful).
It took me a while to figure out what the three offerings were, so I've re-worded them, below, in a way I hope is simpler:
I believe Marija was asking whether people prefer:
(I hope it got it right. Please delete this comment if it's not accurate.)
Without knowing how long option 2 and option 3 are estimated to take, or whether the RSC and other changes would cause difficult migration or breaking changes between MUI 6 and MUI 7, it's difficult to vote with confidence. Option 1 seems like the safest option even though it is slowest, as all dependencies will be figured out before release.
+1 for option 1 :) but option 2 is fine if RSC is too much work
There is already a lot on the mui v6 wishlist as of today and I assume it will take some time to do all of those things or at least most of them, so to me it would be good to make a v6 release without material you first to get all those things out asap, the most important thing to me is that mui works perfectly with server components, I see every major react framework now adopting them, if mui is slow on transitioning to statically generated css then users might switch to other UI packages that do (chakra (panda css), tailwind ui, ...)
then after the new styling system is in place, "material you" could get implemented, second argument is that I'm also very interested in seeing where joy goes and might actually use joy and not material you / material ui for future projects if joy supports all the components that mui does, I say this because I mostly work on mobile apps using capacitor and don't want my apps to look like android apps on iOS, I want something like joy that is more "neutral" and that I customize a lot myself
this is why I chose 3
My vote would be for 1 or 3. I think having Material You opt-in (if it's included) is a good way to ease folks into it. 3 is attractive if it'll take a significant amount of additional time to achieve 1, for similar reasons that @chrisweb articulated. I'm not particularly interested in the Joy side of things, but getting ESM support for me is extremely important, and if achieving #1 significantly delays that, then I'd rather have it without the initial Material You support.
Hey Everyone! I’m happy to share that the work toward adopting Material You has started and we’re looking for contributors to help us 🚀
In the description of this issue, you will find a contributing guide on how to migrate a component to implement Material You specs, as well as a list of the components and their migration status. This issue will act as the umbrella issue for this effort.
If you have any questions, feel free to reach out 😊.
Very excited about this.
Love the chip playground ❤️
Is there a dedicated playground for every component? Or perhaps a subdomain (previously next.mui.com), where I can see a dedicated page for Material UI 6 components?
I'm in the process of adapting Material UI 5 to adhere to the design specs of Material Design 3 right now
@NawarA Currently, there is no dedicated page for the components. If we do that in the future, we will announce it here.
With each component we migrate, we will add a playground. I added the link to each component's playground in the progress section of this issue's description.
I'm in the process of adapting MUI 5 to adhere to the design specs of Material 3 right now
May I ask if you are doing this for a specific project?
@DiegoAndai
Yeah, doing it for Bytez.com.
My first project that used MUI 5 adapted to Material 3 was Seed Swipe, an internal tool I built (Tinder for Investors) I used to meet/match with hundreds of investors. My current project is Bytez.com, where we'll adopt the tokenization and theming to the specs of the handful of components described in the Material 3 standards.
I'd 100% share my work, but not sure the easiest way to do that.
The most important thing, in my opinion, is the MUI 6 has an easy way to generate a theme with primary, secondary, tertiary colors, and the theme has built in tokenization for type-scale, shapes, elevation, and colors.
Once you have a theme that has these CSS rules built in, then its all about using Box components or Sx to apply them to create cards, chips, or whatever the component the spec describes.
So to me, the theme is the foundation, and then it makes it really easy to build any component.
Happy to share my work as I go along. Do we have a Material 6 theme generator?
If not, I think that could serve as the foundation of all work.
@NawarA I would love to see it
As a note for anyone who still needs a current Material 3 implementation for React and cant wait for MUI to update, https://konstaui.com/ has implemented a full set of Material 3 components.
As a note for anyone who still needs a current Material 3 implementation for React and cant wait for MUI to update, https://konstaui.com/ has implemented a full set of Material 3 components.
Where can we get access to the material 3 colors in konstaui?
@pramod-tardigrade It generates material 3 colors based off a provided color, as follows: https://konstaui.com/react/colors
Then it exposes those as tailwind config colors, so you can use them in tailwind classes like 'bg-primary'. If you want to access the colors directly- tailwind.config is just a json file, so access the desired field under theme.extend.colors after importing the JSON.
Hey everyone! You might have seen the announcement about Material UI 2024 releases.
I wanted to reassure everyone interested in Material 3 that we're not delaying this work. We're just adding a major release in between as we think that will be a smoother update experience.
You'll continue to have access to the Material 3 components via the material-next
package. We also hope the ongoing contributions to this effort continue.
I'll move this issue and related ones into the Material UI v7 milestone.
Could anyone provide an example of integrating material-next
into a new React project? we are starting from scratch and not migrating from v5.
I've checked the discussion in this GitHub issue, but it references a project that hasn't been published as a library yet.
Any guidance or examples would be greatly appreciated.
Hey @pramod-knidal, we're working on a guide on this, but here's a sneak peak in the meantime:
npm install @mui/material-next @emotion/react @emotion/styled
(Or your preferred package manager)
After this, the steps are the same as for the @mui/material
package. You should follow the Material UI installation guide from the Peer dependencies section forward.
import * as React from 'react';
import Button from '@mui/material-next/Button';
import { CssVarsProvider } from '@mui/material-next/styles';
export default function MD3ButtonUsage() {
return (
<CssVarsProvider>
<Button variant="filled">Hello world</Button>
</CssVarsProvider>
);
}
(Here's this example as a CodeSandbox)
I hope this helps and that your project goes well. Any feedback, or even better, contributions, for the Material 3 components will be greatly appreciated 😊.
The detailed version of this guide should be released soon. I'll post it here when that happens.
Hey @pramod-knidal, we're working on a guide on this, but here's a sneak peak in the meantime:
Thanks for the quick response. Much appreciated.
if we want to use a custom color to generate the m3 color palette and use that, how is that done?
If we want to use a custom color to generate the m3 color palette and use that, how is that done?
:warning: We just merged a change on how to do this, so the following example will be available from the next release, which should be @mui/material-next@6.0.0-alpha.116
next week.
import { extendTheme, CssVarsProvider } from '@mui/material-next/styles';
const customTheme = extendTheme({
ref: {
palette: {
primary: {
0: '#000000',
10: '#002020',
20: '#003738',
30: '#004F51',
40: '#00696B',
50: '#008587',
60: '#00A1A3',
70: '#00BEC1',
80: '#2DDBDE',
90: '#8FF3F4',
95: '#B2FEFF',
99: '#F1FFFF',
100: '#FFFFFF',
},
},
},
});
export default function App() {
return (
<CssVarsProvider theme={customTheme}>
// ...
</CssVarsProvider>
);
}
You can use Material's Figma MD3 Theme Builder plugin to generate the palette tones.
const customTheme = extendTheme({ ref: { palette: { primary: { 0: '#000000', 10: '#002020', 20: '#003738', 30: '#004F51', 40: '#00696B', 50: '#008587', 60: '#00A1A3', 70: '#00BEC1', 80: '#2DDBDE', 90: '#8FF3F4', 95: '#B2FEFF', 99: '#F1FFFF', 100: '#FFFFFF', }, }, }, });
why do i need to generate palette for m3? the official m3 builder just accepts a primary color and generates the palette.
I guess, what you're asking about, is whether there's a function to dynamically generate a palette from a single spot color? That would definitely be a useful feature. Has MD published that algorithm?
@michaelfaith they have!: https://github.com/material-foundation/material-color-utilities
If someone is interested, it would be nice to have an example of integrating those utilities with material-next
. I would start by installing both packages separately and see if it's easy to wire them together on the developer's side.
@pramod-knidal for now (when @mui/material-next@6.0.0-alpha.116
releases), you must manually provide the palette. The theme builders export the tokens, so you should be able to copy paste (again, when the next release goes live next week).
@pramod-knidal for now (when
@mui/material-next@6.0.0-alpha.116
releases), you must manually provide the palette. The theme builders export the tokens, so you should be able to copy paste (again, when the next release goes live next week).
so, how is the primary palette used? are other m3 colors (secondary, tertiary, error, background, etc.,) generated internally?
so, how is the primary palette used? are other m3 colors (secondary, tertiary, error, background, etc.,) generated internally?
You'll need to provide the tonal palette for all color roles you'd like to customize. If you provide the primary palette, like in the example, only the primary color changes. Nothing is generated internally. I recommend checking out the material-color-utilities
and see if that helps. Let us know if you do. For more information check out Material 3's color system.
You'll need to provide the tonal palette for all color roles you'd like to customize. If you provide the primary palette, like in the example, only the primary color changes. Nothing is generated internally. I recommend checking out the
material-color-utilities
and see if that helps. Let us know if you do. For more information check out Material 3's color system.
assuming that i do provide all the palettes, how would material-next
package use them internally? would it use to theme the components the way it is defined in m3 standard?
Would it use to theme the components the way it is defined in m3 standard?
Exactly, the material-next
theme structure follows the MD3 token structure. For example, the specs for the primary filled common button's background color is mapped as such:
This is implemented with CSS Variables in the material-next
's Button component, which has:
background-color: var(--md-sys-color-primary)
And
--md-sys-color-primary: var(--md-ref-palette-primary-40, #6750a4) /* the second value is a fallback to the default theme */
So when you provide ref.palette.primary[40]
to the theme, that value is used for the --md-ref-palette-primary-40
variable, replacing the color.
It's important to provide all the tones (0
, 10
, 20
, ..., 99
, 100
) as those are used for other components states and modes. You can see this in more detail in the Common buttons specifications as well as the Button component's playground.
@michaelfaith they have!: https://github.com/material-foundation/material-color-utilities
If someone is interested, it would be nice to have an example of integrating those utilities with
material-next
. I would start by installing both packages separately and see if it's easy to wire them together on the developer's side.
Thanks! That looks promising. I'll check it out.
@DiegoAndai Opened issue for List https://github.com/mui/material-ui/issues/40368
I wonder if md3 styles are going to be applied and md2 styles removed in the next major version.
I wonder if md3 styles are going to be applied and md2 styles removed in the next major version.
As the 2024 release plan announcement mentions, Material 3 (MD3) is not planned for the next major version, v6, but the one after that, v7.
For people relying on Material 2 (MD2) styles: When the components with MD3 design are released, there will be a smooth transition path from MD2 to MD3. It's too early to know what that transition would look like, but it's a requirement.
For people relying on Material 2 (MD2) styles: When the components with MD3 design are released, there will be a smooth transition path from MD2 to MD3. It's too early to know what that transition would look like, but it's a requirement.
I'm worried about if md2 is removed. Our theme has modified the style a lot so it does not look like md2 (but override styles are based on md2), if we have to rewrite (or test everything) based on md3 to keep it looking the same as what we have today, it will be harder for us to migrate.
I'm worried about if md2 is removed. Our theme has modified the style a lot so it does not look like md2 (but override styles are based on md2), if we have to rewrite (or test everything) based on md3 to keep it looking the same as what we have today, it will be harder for us to migrate.
Don't worry. This exact case is what I was referring to with "there will be a smooth transition path from MD2 to MD3". Whenever I have more detail on how that transition would look like, I'll post it here. We know there are a lot of projects with customized styles over MD2, and we look to provide the best upgrade experience to those projects.
The Material 3 components guide has been released: https://mui.com/material-ui/guides/material-3-components/
I just checked out the @mui/material-next
package and noticed something. the CSS tokens used don't appear to follow M3 guidelines fully. Like the tokens generated by https://material-foundation.github.io/material-theme-builder/ and https://github.com/material-foundation/material-color-utilities are completely kebab-cased (like --md-sys-color-on-primary
) but @mui/material-next
appear to have the last part camel-cased (like --md-sys-color-onPrimary
).
Is this something overlooked or am I missing something? Just saying coz, it would be great if all the libraries using M3 followed it completely (like https://github.com/material-components/material-web) so that they could be drop-in replaced easily and not worry about matching themes.
Hey @JoseVSeb. Indeed, there's inconsistency. I created an issue (https://github.com/mui/material-ui/issues/41136) to review it before the stable release. Thanks for the feedback! 😊
Will there be an ESM release?
Hey @arunmmanoharan. All of our packages support ESM, including material-next
. When the Material Design 3 components are released in their stable version, they will also support ESM.
We're also working on improving the ESM support for v6: https://github.com/mui/material-ui/issues/30671
I scrolled through the comments here and didn't see anything on this - what would adopting material 3 design mean for support of material 2 in future versions of mui?
Hey @singerbj, thanks for reaching out!
what would adopting material 3 design mean for support of material 2 in future versions
It has yet to be decided. I expect to have a decision by the end of Q2 of this year.
I want to take the opportunity to ask you or anyone else interested: How do you think we should handle Material Design 2 moving forward? The community's input on this is essential.
I want to take the opportunity to ask you or anyone else interested: How do you think we should handle Material Design 2 moving forward? The community's input on this is essential.
I'd prefer separate npm packages. MD 2 as legacy maybe.
I want to take the opportunity to ask you or anyone else interested: How do you think we should handle Material Design 2 moving forward? The community's input on this is essential.
@DiegoAndai wasn't it already decided in this discussion thread? (link to MUI maintainer's comment)
@o-alexandrov, thanks for linking this. Honestly, I wasn't aware of it. It has valuable insights. The community leans towards separate packages and smaller bundle sizes. Having a legacy Material Design 2 package makes sense as an option.
I'm sure you're tracking the pulse of material design standards like me and others. That being said, material ui version 3 is out.
We should track MUI being migrated from Material Design v2 to Material Design version v3.
I'm sure they'll be a few tickets that come out requesting the adoption, so I figured this ticket could act as a stub and catch-all for MUI support for the design language's latest update.
Cheers
References
Design kits
Real adoptions of Material You in the wild?
Desktop
Mobile
Migration
If you wish to contribute, start with the contributing guide
Progress
List of components and their current migration status
✅ Done
- [x] Badges: [Playground](https://mui.com/material-ui/react-badge/#material-you-version) | [Issue](https://github.com/mui/material-ui/issues/37835) | [Specs](https://m3.material.io/components/badges/overview) - [x] Chips: [Playground](https://mui.com/material-ui/react-chip/#material-you-version) | [Issue](https://github.com/mui/material-ui/issues/38024) | [Specs](https://m3.material.io/components/chips/overview) - [x] Circular Progress Indicator: [Playground](https://mui.com/material-ui/react-progress/#material-you-version) | [Issue](https://github.com/mui/material-ui/issues/39770) | [Specs](https://m3.material.io/components/progress-indicators/overview) - [x] Common Buttons: [Playground](https://mui.com/material-ui/react-button/#material-you-version) | [Issue](https://github.com/mui/material-ui/pull/34650) | [Specs](https://m3.material.io/components/buttons/overview) - [x] Dividers: [Playground](https://mui.com/material-ui/react-divider/#material-you-version) | [Issue](https://github.com/mui/material-ui/issues/39007) | [Specs](https://m3.material.io/components/divider/overview) - [x] Linear Progress Indicator: [Playground](https://mui.com/material-ui/react-progress/#material-you-version) | [Issue](https://github.com/mui/material-ui/issues/39778) | [Specs](https://m3.material.io/components/progress-indicators/overview) - [x] Sliders: [Playground](https://mui.com/material-ui/react-slider/#material-you-version) | [Issue](https://github.com/mui/material-ui/issues/37527) | [Specs](https://m3.material.io/components/sliders/overview)⏳ In progress
- [ ] List: [Issue](https://github.com/mui/material-ui/issues/40368) | [Specs](https://m3.material.io/components/lists/overview) - [ ] Menu: [Issue](https://github.com/mui/material-ui/issues/39521) | [Specs](https://m3.material.io/components/menus/overview) - [ ] Select: [Issue](https://github.com/mui/material-ui/issues/38972) | [Specs](https://m3.material.io/components/menus/specs) - [ ] Snackbar: [Issue](https://github.com/mui/material-ui/issues/39207) | [Specs](https://m3.material.io/components/snackbar/overview) - [ ] Switch: [Issue](https://github.com/mui/material-ui/issues/39886) | [Specs](https://m3.material.io/components/switch/overview) - [ ] TextField: [Issue](https://github.com/mui/material-ui/issues/38374) | [Specs](https://m3.material.io/components/text-fields/overview) - [x] InputBase: https://github.com/mui/material-ui/issues/38372 - [x] FormControl: https://github.com/mui/material-ui/issues/38411 - [ ] Buttons - [ ] Button Group (named Segmented Button in the specs): [Issue](https://github.com/mui/material-ui/issues/39686) | [Specs](https://m3.material.io/components/segmented-buttons/overview) - [ ] Icon Button: [Issue](https://github.com/mui/material-ui/issues/39943) | [Specs](https://m3.material.io/components/icon-buttons/overview)⭐ Ready to take
- [ ] [Bottom App Bar](https://m3.material.io/components/bottom-app-bar/overview) (Previously included in App Bar) - [ ] [Bottom Sheet](https://m3.material.io/components/bottom-sheets/overview) (Previously included in Drawer) - [ ] [Buttons](https://m3.material.io/components/all-buttons): - [ ] [FAB](https://m3.material.io/components/floating-action-button/overview) - [ ] [Extended FAB](https://m3.material.io/components/extended-fab/overview) - [ ] [Card](https://m3.material.io/components/cards/overview) - [ ] [Dialog](https://m3.material.io/components/dialogs/overview) - [ ] [Navigation Bar](https://m3.material.io/components/navigation-bar/overview) (Previously named Bottom Navigation) - [ ] [Navigation Drawer](https://m3.material.io/components/navigation-drawer/overview) (Previously included in Drawer) - [ ] [Navigation Rail](https://m3.material.io/components/navigation-rail/overview) (Previously Drawer “Mini” variant) - [ ] [Search](https://m3.material.io/components/search/overview) (New component) - [ ] [Side sheet](https://m3.material.io/components/side-sheets/overview) (Previously included in Drawer) - [ ] [Tab](https://m3.material.io/components/tabs/overview) - [ ] [Top App Bar](https://m3.material.io/components/top-app-bar/overview) (Previously included in App Bar) - [ ] [Typography](https://m3.material.io/styles/typography/overview)✋🏼 On hold
- Blocked - [ ] Autocomplete: [Issue](https://github.com/mui/material-ui/issues/39963) | [Specs](https://m3.material.io/components/menus/specs) - Waiting for Base UI’s hook: - [ ] [Checkbox](https://m3.material.io/components/checkbox/overview) - [ ] [Radio Button](https://m3.material.io/components/radio-button/overview) - [ ] [Tooltips](https://m3.material.io/components/tooltips/overview)