Use @container instead of @media query for Grid

[Exahilosys]

Duplicates

• [x] I have searched the existing issues

Latest version

• [X] I have tested the latest version

Summary 💡

Among the latest CSS specifications is the @container query which I believe could be seamlessly integrated with the Grid component to bring truly isolated responsive component irregardless of screen size.

Examples 🌈

The top-level api for Grid could remain the exact same for backwards compatibility.

A new isolated prop could be introduced to signal the usage of @container like so:

<Grid container isolated>
  <Grid item>
    I don't care what screen size I'm in!
  </Grid>
</Grid>

I believe that in the future the prop should be set to true by default, but for the time being whoever wants to opt-in to this app-wide could override their theme's defaultProps.

Motivation 🔦

I have found myself having to keep track of where I use each component in my app.

This means that their implementation and appearance is (to some degree) dictated by where they are placed, which goes against the isolation paradigm that components are trying to solve to begin with.

[siriwatknp]

Thanks for the feedback! I agree that the CSS container query will bring a lot of benefits to the layout. However, we should be specific on the use cases that the container query + Grid would solve.

Do you have an example where using <Grid isolated> would solve the issue? also please explain the issue first.

[Exahilosys]

Hello and thank you for taking a look into this! I'd be glad to clarify further.

I will try to demonstrate the issue with an example, take these person inputs:

The background color is lightblue for demonstration purposes.

If the screen size drops bellow sm, their fields rearrange to acommodate the tighter space like so:

However, for the initial screen size, if a component is placed next to them that takes up half the width, this would happen:

The fields no longer re-arrange as the screen size has not changed, but their container size has been reduced significantly. They are not responsive to their container, they are responsive to the screen exclusively.

If the fields were responsive to the size of their container (rather than the screen), they would rearrange themselves as shown before, regardless of what's around them.

The solution to this issue with the current implementation would be to simply re-arrange the breakpoints so that it specifically works with this new (hypothetical) component taking up 50% of the viewport width.

What if this component doesn't have to show, or goes away during use? The forms would expand to take up the whole screen, but the fields would remain as if they are still accommodating same the tight space as before.

Their behavior is not tied to their parent component, but rather the screen.

My idea did not replace the container prop nor the item prop. I am proposing a new isolated prop that will work alongside container to signal the use of the new container css attribute for the parent and the @container css query for the direct children. Granting them responsiveness in respect to a specified container, rather than the screen.

I say "direct" children although that is not necessary, the cascade for @container will look upward in the DOM tree and apply itself on the first container element found. This means that the grid items utilising this feature should have a way to to either "opt-in" or (in case isolated becomes default) "opt-out" of using the query, in case it is meant for further nested items.

Please let me know if you need any further clarification. I believe this feature will be right at home with the responsive design concept this library offers so effortlessly.

PS: Stack should probably be subject to this suggestion.

[RELNO]

Thanks @Exahilosys. I support this change, and provided a boilerplate example of the issues with current breakpoints here https://github.com/mui/material-ui/issues/34605

[mstgms]

Is there any progress for this issue? If adding any prop like isolated to Grid or setting on the theme for container query support, it will very useful and powerful for our responsive purposes on divided areas.