You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 8, 2022. It is now read-only.
Hey I'm on one of the teams using this library and we've used it to ship out multiple features / projects with it. I think it's really well written and documented and there's always constant improvements!
It seems that to my understanding MGOV and CMS design system take alot of inspiration IMO from Bootstrap. https://getbootstrap.com/docs/5.0/getting-started/introduction/. I've used almost every major CSS library out there for years so I recognize these patterns
In a bootstrap grid layout setup, the defacto container class is actually set to something that looks more like this when transpiled to it's base CSS definition
why does this matter that ds-l-container from CMS/MGOV is different than container in Bootstrap?
Bootstrap is well battle-tested on twitter and many other companies. Most other CSS libraries based standards around it as well, it's the defacto CSS library standard on the web
The core issue with using a fluid container as the default is this:
A grid system is designed to be used around discrete values. E.g. there's a col-6, col-md-6, col-lg-6, etc for creating different respective column width %.
One of the core value principles of a grid system is predictability from both a coding and design perspective. Most designers who use sketch, figma, Invision generally create mockups for Mobile & Desktop view, and sometimes a tablet view on rare occassions.
The designer has in mind a grid system, generally speaking. They are creating predictable layouts at 2 discrete breakpoints, and the frontend developer generally extrapolates the rest. This is true for almost every company I worked at and peers I know as well
A grid system is wrapper around a container. That container should also be predictable at discrete breakpoints.
Where the general formula for design looks something like this:
Generally speaking, a design system grid layout should expedite the developer experience for both the designer + developer.
We have run into issues where the unpredictable layouts in the current system are causing additional UX testing at random values.
Conversations like this have occured, to hit the point home:
This site looks great at 648px!
but it doesn't look good at 680px
even though our breakpoint at sm=544px, and md=768px
The defacto standards for grids IMO
From my experience, most developers/designers will generally write a grid system based on these parameters.
I will write it based on bootstrap standards
<div class="container-fluid">
Put content and custom media queries in here
</div>
This pattern is very common IMO if your building a Splash Home Page where grid layouts aren't the general convention. Some might include a row or col-12 inside the container to maintain standards and not have to worry about inconsistent margin/paddings across the app. And then they'll write custom media queries here in Sass
For more heavy, intensive informational layouts, a grid system is used usually
As to what the max-width values are at different breakpoints, that's up for discussion
The other option is to change ds-l-container to be a static and not a fluid implementation, but that would probably cause backward compatibility across other apps.
Hey I'm on one of the teams using this library and we've used it to ship out multiple features / projects with it. I think it's really well written and documented and there's always constant improvements!
We've just started recently building full-page layout apps using the grid system proposed here https://cmsgov.github.io/mgov-design-system/utilities/grid/
Here's an example of code straight from that link above
I noticed there are some potential issues with this system. Namely in that
ds-l-container
is set to these propertiesIt seems that to my understanding MGOV and CMS design system take alot of inspiration IMO from Bootstrap. https://getbootstrap.com/docs/5.0/getting-started/introduction/. I've used almost every major CSS library out there for years so I recognize these patterns
In a bootstrap grid layout setup, the defacto
container
class is actually set to something that looks more like this when transpiled to it's base CSS definitionWhere screen-min's mixin is defined like such:
and Bootstrap suggests using it as such:
why does this matter that
ds-l-container
from CMS/MGOV is different thancontainer
in Bootstrap?Bootstrap is well battle-tested on twitter and many other companies. Most other CSS libraries based standards around it as well, it's the defacto CSS library standard on the web
The core issue with using a fluid container as the default is this:
A grid system is designed to be used around discrete values. E.g. there's a
col-6
,col-md-6
,col-lg-6
, etc for creating different respective column width %.One of the core value principles of a grid system is predictability from both a coding and design perspective. Most designers who use sketch, figma, Invision generally create mockups for Mobile & Desktop view, and sometimes a tablet view on rare occassions.
The designer has in mind a grid system, generally speaking. They are creating predictable layouts at 2 discrete breakpoints, and the frontend developer generally extrapolates the rest. This is true for almost every company I worked at and peers I know as well
A grid system is wrapper around a container. That container should also be predictable at discrete breakpoints.
Where the general formula for design looks something like this:
The issue is
ds-l-container
is not following a breakpoint schema. So, based on the current standards of 2.7.0+ releases, this is what it looks like:Generally speaking, a design system grid layout should expedite the developer experience for both the designer + developer.
We have run into issues where the unpredictable layouts in the current system are causing additional UX testing at random values.
Conversations like this have occured, to hit the point home:
The defacto standards for grids IMO
From my experience, most developers/designers will generally write a grid system based on these parameters.
I will write it based on bootstrap standards
This pattern is very common IMO if your building a Splash Home Page where grid layouts aren't the general convention. Some might include a
row
orcol-12
inside thecontainer
to maintain standards and not have to worry about inconsistent margin/paddings across the app. And then they'll write custom media queries here in SassFor more heavy, intensive informational layouts, a grid system is used usually
This is per bootstrap's documentation
SOLUTION
I would suggest creating a new Static container class, since the current defacto class is fluid.
Here is an example:
As to what the max-width values are at different breakpoints, that's up for discussion
The other option is to change
ds-l-container
to be a static and not a fluid implementation, but that would probably cause backward compatibility across other apps.I have written some blog content on this a few years ago if you'd like to read more:
https://www.vincentntang.com/sass-media-queries/
The text was updated successfully, but these errors were encountered: