Grid System for Gutenberg

[mapk]

The Problem

Currently, Gutenberg does not include a visual grid for those site/page builders who wish to align their layouts perfectly. Our system for resizing items is arbitrary and imperfect.

A grid system can help resolve this.

Grid System

With the excitement around snapping images to a grid which was demoed at WCEU 2019 in Matt's keynote, let's get this conversation started.

Questions
I'm trying to get all the questions up front. If there are others, please comment with them.

1. Should the grid system be responsive?
2. Should there be a default Gutenberg grid system, but allow themes to register their own?
3. Should the grid system conform to the current structure of Gutenberg blocks, or should it be its own thing that we need to restructure the blocks to in the editor?
4. Should the grid include gutters?
5. Should the grid include, or allow, any vertical alignment snaps?
6. What should the grid be based on? (ie. 12 columns, pixel grid, etc.)
7. Should the grid allow toggling on/off? And also include a setting to show, or not, when resizing objects in the editor?

While many of these questions can be worked out in individual PRs as we begin working a grid into the editor, I'd like to begin discussions here for now. Maybe we can work on an MVP, or version 1 for now to get into the plugin for testing.

[swissspidy]

Two things I think need to be considered are grids within a block that applies to its inner blocks only, plus horizontal grid lines. So this needs a flexible enough API for plugins and themes to customize the grids for snapping. Example use case for me would be the AMP plugin's AMP Stories editor, which could make use of this.

[karmatosed]

Some thoughts:

Should the grid system be responsive?

Yes, absolutely. Although, this brings up having multiple grids and maybe that's also an option to allow declaring of multiples.

Should there be a default Gutenberg grid system, but allow themes to register their own?

Yes, and it should be documented to encourage people to easily be able to adapt.

Should the grid system conform to the current structure of Gutenberg blocks, or should it be its own thing that we need to restructure the blocks to in the editor?

I think restructuring is a massive step. Perhaps starting with what there is right now and seeing potential restructure as an iteration is a better-stepped process here.

Should the grid include gutters?

By default probably, but having gutters as an option could be a case. Most grids would have gutters.

Should the grid include, or allow, any vertical alignment snaps?

I think snapping to grid feels like an option or a step after having a grid. I see a great need for it and want, but like with most image software grid snapping is on option, I think it should be for Gutenberg. We may decide it's an option on by default though, I can see a strong case for that.

What should the grid be based on? (ie. 12 columns, pixel grid, etc.)

I think this is the 'fun' bit. Starting with what we have as a base, I think then exploring what other grids feel or are like is a great exercise in experimentation.

Should the grid allow toggling on/off? And also include a setting to show, or not, when resizing objects in the editor?

I think allowing it to show/hide is essential. As mentioned earlier I also think there could be a case for other options to be added in. I go back to think about how Sketch and other applications do this.

It would be great to maybe step away for a moment and do some thinking about what applications offer this. What features do they have and what can we learn?

[mapk]

I think restructuring is a massive step. Perhaps starting with what there is right now and seeing potential restructure as an iteration is a better-stepped process here.

Thinking through this, I worked on a grid largely influenced by Material.io. I haven't thought through the breakpoints or provided other screensize examples yet, but maybe this can help the conversation?

This grid contains columns and gutters.

Columns vary depending on breakpoint. At the default Gutenberg 580px width, the grid would include 8 columns and 7 gutters. The column widths are fluid up to the breakpoint in which case the column count changes up to 12 (wider content area) or down to 4 (smaller content areas). The gutters are fixed width and change their widths only at breakpoints.

I know this is an opinionated approach to grids, but I think it's necessary to implement. Themes should be allowed to register their own grids, but as a default Gutenberg grid, this should be sufficient.

If anyone has other ideas or feedback on grids, I'd love to hear more! There's an experimental PR going on #16748, so I'd like to move on the grid discussion.

[kjellr]

@mapk Because of wide + full alignments, I think the grid will need to extend beyond just the text column right?

[mapk]

Great question, @kjellr. I wasn't sure how to treat those. The idea of wide and full alignments, in my mind, pushed beyond the grid. Although, I can see wide needing to align with a grid pattern still, so in that case, it's probably a good idea to extend the grid further.

The grid breakpoints would still be defined by the post content, but the grid pattern would extend beyond. Here's a few examples.

Option 1 - Lines

Option 2 - Fills

[karmatosed]

The idea of wide and full alignments, in my mind, pushed beyond the grid. Although, I can see wide needing to align with a grid pattern still, so in that case, it's probably a good idea to extend the grid further.

I agree with @kjellr and it should extend. I don't think you need to show it until they have been added though as easier visually without.

[paaljoachim]

What about a grid switch and a block border switch in one? Kinda like turning on the grid feature in Photoshop to see all the elements and how they relate to each other.

[senadir]

Should the grid system be responsive?

This is a must, but how can get this is the actual problem, responsive grids are relative to the medium you're seeing them, so how can we translate those values from say, the editor, to the frontend.

Should there be a default Gutenberg grid system, but allow themes to register their own?

yes, this is definitely a must, mostly for easier adoption.

Should the grid system conform to the current structure of Gutenberg blocks, or should it be its own thing that we need to restructure the blocks to in the editor?

I think we can start with a simple structure, the PR i made #16748 inject the grid at the root of the editor & communicate it with other blocks, blocks can choose to integrate it, this can help in a gradual adoption.

Should the grid include gutters?

a default grid behavior have gutters, but i twill be hard to resize & snap with gutters in place since it will be a lost space.

Should the grid include, or allow, any vertical alignment snaps?

for the moment no.

What should the grid be based on? (ie. 12 columns, pixel grid, etc.)

this is the problem I'm thinking about right now, grids have the fluidity of adopting any screen size.
pixel grid is more straightforward, easier to adapt with the editor, and much to understand to a normal user (3 columns are 300px for example) but they prove to be very hard to translate & interpolate at different screen sizes, snapping to columns might prove hard when you want to do out of the grid alignment.
the technical implementation of pixel grid & percentage grid will be different so we might choose a way & go with it for now and add the second one in the future, it will however, prove hard to migrate from a theme that uses % to a theme that uses px.

Should the grid allow toggling on/off? And also include a setting to show, or not, when resizing objects in the editor?

this is currently how it works in the PR, i guess it makes sense, we can add an option to toggle it off & on in the editor, and for it to toggle on & off in the snapping & resizing moments.

a live demo for some UX testing, it uses px columns without a fixed container size.

some other questions to think about

• how should we handle breakpoint transitions?
• how should we implement the snapping behavior? snap after release or snap before release?
• how will different themes defining different grids play with each other? if I change a theme, I mostly expect my content to still work the same
• are subgrids a thing? how can handle them? or should support them to begin with?

[senadir]

for extending beyond the grid limit, I think we should have 1 or 2 stops at max, full length & half length.

think of it this way, if a grid is 1200px and a user screen is 1920px for example, a full length grid stop should make the element 1920px or max width, a half length grid stop should make it 1560px or max width.

if we define more columns outside the container we risk putting ourselves at grid stops that would not translate to the frontend, a 12 column for a base grid is ideal, anything outside should be treated as 100% page width or something.

[mapk]

Should the grid system conform to the current structure of Gutenberg blocks, or should it be its own thing that we need to restructure the blocks to in the editor?

I think we can start with a simple structure,

I agree. The grid I mocked up above conforms to the layout of the starter theme's editor styles. I felt this was a good beginning.

a default grid behavior have gutters, but i twill be hard to resize & snap with gutters in place since it will be a lost space.

Yeah, let's make sure to include gutters on this grid b/c it's a natural grid attribute. I don't think we need to consider this as "lost space" though and rather just allow the user to align to any gridline they'd like to.

the technical implementation of pixel grid & percentage grid will be different so we might choose a way & go with it for now and add the second one in the future, it will however, prove hard to migrate from a theme that uses % to a theme that uses px.

Agreed. I like a percentage grid first with static pixel gutters depending on breakpoints. Similar to Material's grid system. This makes sense. The grid is determined based on the content width within the Editor and Frontend. Once that is determined (ie. mine above shows 8 columns) then that grid pattern is just repeated through the entire screen, not just within the content column. This allows for wide and full-width alignments to work along the grid too.

for extending beyond the grid limit, I think we should have 1 or 2 stops at max, full length & half length.
think of it this way, if a grid is 1200px and a user screen is 1920px for example, a full length grid stop should make the element 1920px or max width, a half length grid stop should make it 1560px or max width.
if we define more columns outside the container we risk putting ourselves at grid stops that would not translate to the frontend, a 12 column for a base grid is ideal, anything outside should be treated as 100% page width or something.

I think we need to allow this grid pattern to repeat, but using color or fill indicators to designate the "content area" should help with layout. But ultimately, as we look to pull in other Block Areas into this editor (however that happens) we'll need to allow this grid to extend to those areas too. This beginning sets us up for that. And this ways themes can begin to build with this in mind. Any theme that doesn't allow breaking out of the content area, maybe we either hide the repeating pattern, or not allow items to be extended past it in the editor. Thoughts?

[strarsis]

There is a great WordPress plugin for a Gutenberg grids block:
https://wordpress.org/plugins/grids/
The only one I was able to find that allows customizable grids.

[strarsis]

IMHO the grid in Gutenberg shouldn't necessarily reflect CSS or HTML grids or its concrete implementation. Even sub-grids, if not supported could be emulated using JavaScript.
So the user interacts with a high-level grid, regardless of implementation or CSS support.

[karmatosed]

As this now has a lot of feedback, I think changing the label to 'needs decision' makes sense.

[aquaihoi]

It just needs to be like a page editor for print . . . With either grid or column toggle on or off to show a grid used for alignment, also it would be good to have a decent menu system similar to any word processing with grouped embellishments, font selection etc. etc. I quite like the way the GRIDS plugin allows you to draw grids / sections etc. but without a design / layout grid system the Gutenberg editor is over simplified, its like you’re working blind

[strarsis]

@aquaihoi: There is also full page editing that is still alpha in Gutenberg.
However, grids in content are still necessary.

[paaljoachim]

The Grid Layout Block has been built for wordpress.com.
https://wordpress.org/plugins/layout-grid/
I do think we can improve on it and get it into Gutenberg Core.

Actually we could get drag handles into the Columns Block.

[aquaihoi]

Coming from desktop publishing background, it would be really awesome to see DTP implementation of more tools, features, conventions which are translated over to the page editing interface of core wordpress, not just for me but a lot of people, who have a phobia of designing for the web, earlier on we would be juggling dreamweaver, css, html, php over and in-between to design web pages, lets face it, designers are not developers and what is really cool about how Wordpress came to be and the ease of use it allowed the average user to set up pages is really awesome, however the tools and the way you design tends to rely on so many plugin which often leaves the site bloated with plugins, some of which the authors abandon or amalgamate with other companies and the prices go high, native font management and integration would also be cool. Id love to see the editing tool bar landfill screen workspace in the page editor which is similar to any standard word processor or a light version of Illustrator or Indesign - the Gutenberg interfaces soooo close to being an awesome tool that anyone from publishing can pickup and run with, some minor things are very unintuitive, the basic structure is there, but it needs just a little work - for instance - clearly defined space - eg. page size with boarders, eg. my site is 1200 x 1200px in dimension, in which there are grid layouts, and the user can draw text and image boxes, with snapping etc to compose their page, while the core maintains resize and repositioning of blocks for mobile viewpoint, it needs to be a bit more visual, Id love to design up a mock interface show what I mean, I'll try the next instance of spare time I have, will try the plugin on out on a new website project !

[strarsis]

I have to refer again to the Mesh plugin which would be equivalent to Gutenberg Full Page Editing.
It is important for themes to have as much control as possible, the grids defined by user should be modifiable by the theme, in terms of breakpoints, columns, rows and even position (CSS Grid).

[LukaszJaro]

This would be great, my previous project I used blocks inside the content and outside the content I was styling with Bootstrap 4, it became a little disjointed, lacked consistency and I wondered why I was using two CSS frameworks.

I do like the bootstrap approach of adding classes to html which I was also able to use and add inside the content through the custom classes. It was also helpful to have responsive margin and padding classes.

A grid system that you can also use practically outside the content would be great.

[kelleymuro]

I'm super interested in this even if it is simply in the context of patterns. Being able to create certain pattern types (Grid Enabled) that empowers users to start with a template but easily customize them. Ultimately I would like to see entire sites being created with a snapped grid layout. Like Editor X or Squarespace is doing.

I have seen a few examples, what is the decision for vertain blocks vs having many rows and columns to span blocks across. Squarespace a few months back released their Fluid Engine which seems like a pretty efficent way to do things.

Does this introduce a whole new block type where where there is draggable blocks and droppable sections/containers?

Would be fun to experiement with breakpoints

Either way, I would love to sponsor someone that may be interested in working on this with me.

[strarsis]

@kelleymuro: Overlapping cells for the Grids plugin should achieve the same, but this feature isn't implemented yet.
Even better when this grid system could be directly integrated into WordPress Gutenberg core.

[kelleymuro]

@strarsis Did you work on this plugin? It doesn't seem to be as intuitive as I'd like it to be when it comes to freely moving components around a grid.

What I am purposing is to not set your content areas but just automatically set an entire section as a content area and then be able to freely move components around that area.

[annezazu]

Closing this out as the design and experience has evolved substantially since this was first explored. For future work, follow along here where improvements to layout are being explored, including a Grid variation of the Group block first explored in 17.8: #57571