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

[system] Add container queries utility #41674

Merged
merged 17 commits into from
Apr 17, 2024

Conversation

siriwatknp
Copy link
Member

@siriwatknp siriwatknp commented Mar 27, 2024

closes #36670

Context

The reasons I spend time on this:

  • CSS container queries browser support is very high (~91%) which is considered production-ready
  • The community has been waiting for a year and the requests keep coming
  • It's a nice addition for v6 that we can add to a blog post

✅ Need decision

I decided to make it a default theme. cc @DiegoAndai

Should we add container queries to the default theme or should it be opt-in?


@siriwatknp siriwatknp added new feature New feature or request package: system Specific to @mui/system labels Mar 27, 2024
@@ -1,3 +1,3 @@
export default class MuiError {
constructor(message: string);
constructor(message: string, ...args: string[]);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Come across this since my test is the first .ts that uses MuiError with multiple parameters.

@mui-bot
Copy link

mui-bot commented Mar 27, 2024

Netlify deploy preview

@material-ui/core: parsed: +0.26% , gzip: +0.26%
@material-ui/lab: parsed: +0.52% , gzip: +0.57%
@material-ui/system: parsed: +1.82% , gzip: +1.64%
@mui/joy: parsed: +0.30% , gzip: +0.40%

Bundle size report

Details of bundle changes (Toolpad)
Details of bundle changes

Generated by 🚫 dangerJS against 885caa5

@DiegoAndai
Copy link
Member

Should we add container queries to the default theme or should it be opt-in?

If I understand correctly, this adds functionality but doesn't modify the existing media query one, right? I mean if you were doing

{ xs: { ... } }

You'll still be able to do it, and with this change you can add custom queries

{ xs: { ... }, '@350': {...} }

So isn't it opt-in by design? Is there something else you refer to with "should we add container queries to the default theme"?

@siriwatknp
Copy link
Member Author

siriwatknp commented Mar 27, 2024

So isn't it opt-in by design? Is there something else you refer to with "should we add container queries to the default theme"?

The changes I made right now are kinda mixed between the two so let's neglect the code for now. We need to decide between

  1. By "adding container queries to the default theme", I mean you can start using the new shorthand after upgrading to v6.
  2. However, if we go with opt-in, developers have to wrap their theme with a new cssContainerQueries and then they can start using the new shorthand (if they don't use the fn, the new shorthand won't work).

@DiegoAndai
Copy link
Member

DiegoAndai commented Mar 27, 2024

you can start using the new shorthand after upgrading to v6

Are there any breaking changes associated with the new shorthand?

  • If yes, I would say we should go opt-in with the cssContainerQueries approach
  • If no, I would say we can add it by default in v6

Regarding browser support, it's important to consider it when users cannot opt out of features. For example, if we use the CSS property gap to implement a component, then the component cannot be used in browser versions that don't support gap. This case is different because if a user needs to support a browser version that doesn't support CSS container queries, they can still use the library and avoid the new shorthand feature, right? This is what I meant with this new shorthand feature being "opt-in by design".

@elyseholladay
Copy link

This case is different because if a user needs to support a browser version that doesn't support CSS container queries, they can still use the library and avoid the new shorthand feature, right? This is what I meant with this new shorthand feature being "opt-in by design".

As a user, I'd prefer it to be the default, so I don't have to wrap their theme with a new cssContainerQueries. Container queries, as @siriwatknp noted, are pretty well supported. If @DiegoAndai is correct above and you can just choose to use the additional query or not, and nothing else changes in the responsive queries, why not just make it the default?

@siriwatknp
Copy link
Member Author

siriwatknp commented Mar 28, 2024

if a user needs to support a browser version that doesn't support CSS container queries, they can still use the library and avoid the new shorthand feature, right? This is what I meant with this new shorthand feature being "opt-in by design"

Yes, that's correct. It's the responsibility of developers to check browser support before using it.

why not just make it the default?

Because there will be computation overhead (the impact is based on the project size) for those who don't want to use container queries. This is the only concern I have.

Anyway, I don't mind making it as a default too.

@siriwatknp siriwatknp marked this pull request as ready for review April 3, 2024 06:19
@siriwatknp
Copy link
Member Author

@DiegoAndai @mnajdova Would you mind taking a look at this PR again?

Copy link
Member

@DiegoAndai DiegoAndai left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good overall, just have a couple of minor questions

@@ -9,6 +9,7 @@ describe('defaultTheme', () => {
'colorSchemeSelector',
'defaultColorScheme',
'breakpoints',
'cq',
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we (or should we) use containerQueries/containerQuery instead of cq?

Copy link
Member Author

@siriwatknp siriwatknp Apr 11, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, it can be explicit on this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let me know if you decide to implement this change or not 😊

Copy link
Member Author

@siriwatknp siriwatknp Apr 12, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done! changed to containerQueries (with ies)

}

/**
* For using in `sx` prop to sort the breakpoint from low to high.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this function only used for the xs, sm, md, lg, and xl queries?

I'm wondering as it only supports min-width declarations.

Copy link
Member Author

@siriwatknp siriwatknp Apr 11, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, it supports valid CSS units like 40em or 300px but it requires all fields to use the same unit.

sx={{
  flexDirection: {
    '@300px': 'column',
    '@500px': 'row',
  }
}}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But it only supports min-width ones, right? So, for example, theme.cq.down, which outputs @container (max-width:...) won't be sorted correctly.

I want to better understand this function's use case. Is it internal or also for users?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The sorting only happens for the sx prop (happens internally, the function isn't meant for users) similar to theme breakpoints shorthand.

Copy link
Member

@DiegoAndai DiegoAndai left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work @siriwatknp 🚀

@siriwatknp siriwatknp merged commit 3b3f08c into mui:next Apr 17, 2024
22 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new feature New feature or request package: system Specific to @mui/system
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Extend sx props to support a shorthand for container queries instead of only media queries
4 participants