Grids… for long I have thought they are the trivial bit in front-end development. Many sites do not have much variation in column widths, so to use a ‘grid system’ would be a clear violation of the KISS principle. Now I think complex grid systems can be of great use in component-based front-end builds.
Note that the following may soon be obsolete, when we start describing layout in CSS using CSS Grid Layout (not widely supported at the time of writing)
My view is this: for large websites and organisations, in addition to having a component system, it makes sense to have one agreed-upon, shared-between-projects grid system.
What is a grid system?
By ‘grid system’, in this article, I mean a set of CSS rules written for the purpose of declaring grids in mark-up. These can be hand written, or generated by preprocessors (in which case they can be generated with custom options to fit a project better). Some agencies I worked with have rolled their own. Others use an open source one, such as Bootstrap’s.
Spanning columns through classnames
In this kind of grid system, grids are declared using classnames on HTML elements. Usually classnames are given to each row of columns, and then to each column within that row. A grid has a number of ’virtual’ columns (e.g. 12 or 16). Specific elements span a number of these virtual columns, e.g. a main column could be the first 8 out of 12, then the sidebar could be remaining last 4. In mark-up, classnames of each actual column determine how many virtual columns are spanned.
Complex structures full of features
Grid systems are, more often than not, convoluted structures of code. Not only do they contain percentages for any combination of columns imaginable, they often also have options to ‘skip’ columns, so that an element can start spanning columns after the columns it has skipped. Many also contain percentages per breakpoint, so that you can have different sets of columns per breakpoint. This results in many classnames; time consuming to write, or if generated, buried away in your preprocessor output.
As opposed to the introducing-columns-when-required approach
Note that there are other ways to go about columns and widths in websites. You could just add CSS rules for each grid variation required (eg, you would be done by just writing one for doubles, one for quarters, and perhaps one for three quarters). This is how websites have been built for a long time. I used to prefer this approach — depending on the project, I sometimes still do. It uses a lot less CSS and is very KISS.
How do they fit in component-based front-ends?
The cool thing about component-based front-ends is that none of the component code is committed to specific widths. The width of a component is determined by the container it happens to exist in. Or, if it does not sit in a container, by the window or viewport width.
If your team decides to build pages using a grid system, this is their role: they force what the width is of any components that occur in the page.
To have a super complex grid system, with perhaps more classnames generated than you might actually need, requires clear advantages to be worthwile. The amount of classnames comes with weight: Bootstrap’s default grid system is 8KB (minified). Yet, advantages do exist:
Separation of generic, reusable components and specific, non-reusable widths
You don’t want the development of a new component to involve widths, the width of things will be decided in the context of the page grid and the viewport it exists on. Therefore, a separation between things and their widths makes sense. If the grid is separate, it makes sense to be a powerful (or complex) system that fits many cases, rather than something that is decided case by case.
Great for teams in agencies or organisations
As a team (in an agency or elsewhere), it makes sense to use the same grid system or grid system generator for all projects, with only changes to their setup (eg number of columns, nature of breakpoints). This is not about developer convenience, it is about organisational consistency. You’re making sure all teams in your organisation do the same thing with their widths, just as they do the same thing with their components.
Conclusion
The main benefit of an agreed-upon, shared-between-projects grid system is this. For an organisation, a great level of consistency can be achieved if widths in all of their sites come from one system (just as it helps if components for all of their sites come from one system).
Does that mean I think one grid system will fit all? No, adjustments are probably required sooner or later. That would mean new versions of ‘the grid system’ would get released. All projects within an organisation would be using ‘a’ version of ‘the grid system’. If this happens to be not the most recent version, the project team can decide whether to update to the latest version or not.
Comments, likes & shares
No webmentions about this post yet! (Or I've broken my implementation)