Cancel

Justin Tadlock

Should the Block Editor Have a Grid System?

Laying out a webpage design and getting every element aligned perfectly can be a tough job. Even many developers rely on CSS grid frameworks. Granted, with the introduction of the flexbox and grid systems in the CSS language, such frameworks are becoming unnecessary. Whether it is getting the vertical and horizontal rhythm down or simply aligning an image next to a bit of text, page layouts are often done best via some sort of grid system.

This becomes even more apparent when building a page layout visually through the WordPress block editor. The current iteration of the editor does a fine job of being a general content editor while providing the ability to insert various elements into the page.

However, it is not by any means a page builder — yet.

The question is, before we engage in full-site editing, global styles, block patterns, and other upcoming tools, whether a grid system should be a part of the equation. If so, how should that system work? Will it be configurable by theme authors? How will it handle tablet and mobile views? Will the grid be visible to users or a hidden thing in the background?

As more block plugins are released, particularly with those that may have multiple elements that may need to be aligned, it might be time we consider a grid system. Such a system may benefit existing core blocks right now, such as Columns and Media & Text. Or, it may be better as a separate, standalone block.

Including a grid system also has the additional benefit of standardizing on layout-related class names that theme authors can use in their CSS, even outside the content editor. This would bring better compatibility across the board when users inevitably switch themes.

A Starting Point: Layout Grid Block

Screenshot of the Layout Grid block in the block editor with a basic three columns.
Three-column layout with Layout Grid Block.

Automattic, as part of its Block Experiments project, has released the Layout Grid Block plugin. It is essentially a beefed-up version of the core Columns block. The major difference is that column alignment snaps to a specific point in the grid. This grid is also displayed in the background while editing the post.

The tricky thing with grids is not simple alignment in columns in desktop view. It is dealing with how those columns transform on smaller devices like tablets and smartphones. Sometimes that is a guessing game from a theme design perspective because the theme author is not privy to the actual content that needs to be aligned. In turn, designers make best-guess decisions and hope it works for most.

The Layout Grid block has a “Responsive Breakpoints” tab under the block options panel that allows users to configure this based on device. Users can decide how individual columns span the grid. The grid system is based on a varying number of grid sections based on the device:

  • Desktop: 12 Sections
  • Tablet: 8 Sections
  • Mobile: 4 Sections

Imagine wanting to display a simple image with text to the next of it. There are various ways to do this currently in the block editor. Each has its pros and cons, depending on what you want to do. From a user experience and visual standpoint, I love seeing the grid lines in place as I determine how it should be displayed.

Screenshot of a pizza restaurant menu item with the Layout Grid block.
Aligning an image and text on a grid.

Another upside of having a grid system is consistency in design. If users can scale the width of columns based on arbitrary numbers, much like they can now do with the Media & Text block, there is no consistency with sizing items horizontally on the page. A grid system changes that.

Layout Grid Block still needs some polishing at this point. There are some trivial pain points in the UI that could be improved. On the whole, my experience with this block offered a compelling argument for including a grid system in core.

The plugin addresses simple one, two, three, and four columns right now. The grid system in CSS is much more powerful than basic horizontal columns. However, starting with the basics would give us a place to build from.

Should Core Include a Grid?

There is at least one open ticket on the Gutenberg repository for addressing a grid system. Mark Uraine, the author of the ticket, posted seven key questions:

  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?

The ticket had some solid discussion nearly a year ago but not much as of late. Would you like to see a grid system in the editor? If so, how would you want it to work?

Category: ,
Tags:
18

18 responses to “Should the Block Editor Have a Grid System?”

  2. Some sort of grid system is needed to manage layouts that flow correctly through all the appropriate breakpoints. I am currently using the grid block offering provided in Toolset and it is fairly full featured.

    The default column block is pretty useless as there is no way of easily delineating a gap between the content in each column.

    The problem with all this is that important fully featured layout structures are not being provided early enough in the block editor out of the box, something that all plugin vendors can lean on. This means we are getting a mush mash of different optional alternatives and no standard with the block editor.

    While I have grown to see the block editor as a good step forward for WordPress, my one criticism from the beginning Is that it falls between two stools in not going all out to be a layout builder.

    Create forum topic from comment

    • Yep, the core columns block is still one of those I’m not particularly happy with. The one from Automattic’s plugin mentioned in the post felt much better, albeit with a minor UI issue, which may be related to my theme stylesheet.

      More than anything, I would love to see some sort of standard coming from core that plugin authors can use instead of competing solutions.

      Create forum topic from comment

  3. Is this a trick question? I promise the reason people have been using page builders for at least the last five years is not because of their “cool” (pre-block) modules.

    It’s been to manage layout. The modules are convenient. And many of them are truly clever. But even genuinely bad page builders (and even ridiculous alternatives like ACF Flexible Content fields) can at least lay out a set of columns that
    a) adjust themselves accordingly on different screens without supplemental CSS
    b) handle other annoyances like equal-heights columns and vertical centering.

    All the better page builders (even shortcode-circus ones like Divi and Visual Composer these days) will let you edit in situ, set colors, font sizes, spacing, margins, background images, apply responsive hinting, preview and tweak in tablet and phone screen sizes, set column stacking, and any number of other things most people want to do. Without writing acres of CSS. And especially without doing the silly edit/preview/edit/preview cycle that we had to do with old WordPress and still have to do with Blocks.

    Speaking of edit/preview and CSS, the other day on my local WP community slack channel someone demoed a two-column block, divided evenly, with text on one side and a video on the other. The overlapping was embarrassingly bad. It’s shocking that core container blocks can’t even handle margins properly without user-added CSS.

    I’ve said repeatedly over the years that page builder were the tech equivalent of a blister or callus caused by not being able to do simple layouts in core. That’s still true.

    So to answer your question: yeah, yeah, there needs to be at least a grid system in core. There really needs to be a layout,

    Gutenberg architecture evidently makes it painfully difficult to incorporate blocks into any of the modern page builders. This is not a condemnation of page builders, it’s a condemnation of block architecture. Maybe with their round of venture capital Elementor will be able to make it work. I dunno.

    But one way or another, maybe 15% of all web pages use much more than
    – Text boxes
    – Photos
    – Headers
    – The occasional gallery, form, product, or other widget-y thing.

    But 100% of them need to be laid out, preferably taking less time to do so than it takes to add the actual content. Preferably while adding the actual content. Blocks and the block editor don’t do that.

    A lot of us are pretty tired of hearing people say “well, Weebly/Wix/whatever let me do XYZ.” When they say things like that it’s pretty much always about layout and design. Because that’s usually the only thing those tools are good at. And unfortunately it’s one of the big things users care about.

    So yeah, the block editor needs a grid editor. In core. It needs one just to get into the game.

    Create forum topic from comment

  4. People tend to sometimes get passionate about their grids. Some prefer 12 columns, others prefer 16 or 24, others are happy with 6 and others hate grids.
    A grid would be beneficial only if not enforced. I can see myself using it if I can choose how many columns I want – if any.
    If my design requires me to do golden ratios for some blocks then a grid would prevent me from being able to create what I have in mind. Instead if freeing me it would trap me. And that’s not what WordPress should be like…

    If a grid gets added the user should be able to
    1. Define globally if they want a grid, how many columns they want their grid to be and whether they want gaps between columns and how large these gaps should be
    2. Be able to disable, or even override the global grid in a block.

    And of course if users do get the ability to define their grids, gaps etc under no circumstances should we enforce the use of pixels by implementing slider/range or numeric controls for the size selection etc. I like em units, others like % and then there’s the occasional vw etc.

    A grid is beneficial if it’s by choice and fits the user’s needs. But we can’t know what those needs may be, so we’ll need to be versatile and not enforce what we deem as “reasonable”.

    Create forum topic from comment

  6. I think grids are often needed, although personally I don’t like overcomplicated design, with lots of elements.
    Nested elements look gross for me, and we should instead try to use a “start block” and an “end block”.
    I see the point of the editor not looking in the backend as it would in the frontend, but on the other hand, nesting looks bad, and I think its the main reason for complexity when it comes to the admin.

    Create forum topic from comment

  8. I can’t even imagine using the block editor without a grid block, even a simple one. TBH, this should have been in the first phase of Gutenberg, had it not been so hasten. With it, probably Gutenberg adoption would have worked a little better. Some of the included layout blocks are of very limited use, if any.

    There’s not one project where I used the block editor I didn’t use some third-party grid-like block.

    I’m particularly in love with Tom Usborne’s approach to a layout block plugin, https://generateblocks.com/. You get a container, grid, headline and buttons. No more, no less. I’d say with this package you can solve the majority of layout problems you get with the core blocks.

    Now the issue will be whether including an opinionated grid block will conflict with other grid implementations by themes and plugins. Which

    Create forum topic from comment

  9. Sure, yes 100% but only if it is Boostrap. I’m sure this will elicit 100 booos from haters, but it is extremely well thought out and functional. It also has inbuilt methods for dropdowns, tabs, tooltips, and accordions.

    The problem is due to WP’s obsession with backwards compatibility it could never work. Bootstrap 5 will roll along and then nobody will be willing to update it.

    Create forum topic from comment

  12. Had a look at Automattic’s offering and on the back end I thought it was pretty good and flexible with the responsive options. In itself it would cover the work done by columns and quite a number of layout configurations, though not every conceivable layout.

    Create forum topic from comment

  13. I <3 grids! I’d love to see grids be able to be theme-defined, to give themers maximum control over things like number of columns, gutter, etc. There’ll also need to be consideration around the overall grid in Full Site Editing — should the grid be defined for the entire site, and then the post/page content area only show whatever columns it occupies?

    Create forum topic from comment

  15. Yes, of course there should be a grid in Gutenberg. Its an integral part of any page building tool and the absence of it is the reason why I don’t even try to use Gutenberg for clients websites.
    Every single website i’ve ever built (over 200) needs some kind of layouting. Some need very minimal layouting, like 2/3/4 equal columns, other websites need much more advanced layouting like asymmetrical, overlapping and vertically justified columns.
    So the grid system needs to be very flexible – but easy to use and understand.

    If I were to design a solution for this, I would not make Gutenberg dependend on any existing CSS grid framework like Bootstrap.
    I would instead introduce a new standard in the CSS classes used by the rows and column Blocks (like “wp-row”, “wp-column”, etc.) and make use of flexbox to design a very flexible grid system which does not rely on a certain number of columns. You could add an unlimited number of columns to each row and have the flexbox model take care of the rest, while providing settings on a per-row basis for finer adjustments like equal height columns, vertically aligning the content in each column, gap widths, negative offsets, etc.
    This way, every theme would be compatible and it would be a very modern, futureproof solution, which enables users to build any kind of layout without adding the Wright of any dependency on frameworks to WordPress / Gutenberg.

    Create forum topic from comment

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.