Grid Layout type

[tellthemachines]

What problem does this address?

Following on from #44557, #32443.

What should a Grid layout type look like? What options should it provide?

What is your proposed solution?

Let's assume the limitations of the CSS Grid spec as our boundaries, to make things as simple as possible.

In order to build a grid with more than one column, either grid-template-columns or grid-template-areas has to be defined. grid-template-columns offers more flexibility in terms of responsive behaviour, so let's consider only that option for now. There are essentially two approaches to building a multi-column grid:

• Define a fixed number of columns, which can each have different (relative or fixed) widths;
• Define a (relative or fixed) column width and let grid decide the number of columns based on viewport width.

Option 1 will always display the same number of columns, although if their width is a percentage or fraction of the whole, it will behave responsively. Otherwise horizontal scroll will happen once the grid is wider than the viewport. This requires, at a minimum, setting a number of columns and their respective widths.

Option 2 will adjust the number of columns according to the size of the viewport, but the columns will all have the same width. This is an easier option to set up as it only requires specifying a minimum column width.

Perhaps we could make both options available, defaulting to 2 as the easiest to get started with? What might a UI for these options look like?

In addition to these options, we should allow gap to be set (using the existing block spacing controls) and perhaps optionally row height (although that could be left out of a V1). We could also repurpose the flex justification and alignment controls to some extent.

Cc @WordPress/gutenberg-design for ideas!

[skorasaurus]

might be better discussed in https://github.com/WordPress/gutenberg/issues/16271 which has started to explore this? (also ref https://github.com/WordPress/gutenberg/issues/41234)

[tellthemachines]

@skorasaurus as I understand it, those issues refer to a site-wide system of measurement in the form of a grid. This issue refers instead to a layout type that can be used on individual blocks to apply CSS grid styles to their contents.

The layout type may provide some the technical underpinnings of the grid as a measurement system, but it will benefit from being explored separately from the whole discussion around how a site-wide grid system should behave regarding responsiveness etc., which has been open for almost 4 years without a definite conclusion. Implementing a grid layout type will have immediate benefits at a block level - as discussed in #44557 - and can be kept pretty simple at first, and added to later if we decide to move forward with the site-wide grid system.

[andrewserong]

Thanks for writing this up, too!

Perhaps we could make both options available, defaulting to 2 as the easiest to get started with? What might a UI for these options look like?

I like the idea of giving folks both options, defaulting to 2, with 1 effectively as an "advanced" feature? We could also potentially have a control for minimum column width, to be used in a rule like repeat(auto-fit, minmax(240px, 1fr))...

In case it helps anyone else following along, I'm a little rusty when it comes to working with CSS grid, so I found this article from a few years ago helpful as a recap on how it works: https://css-tricks.com/look-ma-no-media-queries-responsive-layouts-using-css-grid/

[jasmussen]

There's definitely a lot of past explorations in this, including #4314 which sought to use grid to absorb wide and fullwide alignments, while also providing some exciting new ones like "pull left" and others. Then also #20000, which added a bespoke grid block implementing almost the full range of grid properties.

In the former, it broke floats as well as collapsing margins. Both of which today would probably be acceptable for post content as we have an alternate means of spacing out blocks. The latter was slightly encumbered by the weight of features to support, making the block hard to use unless you also knew the behavior of the grid spec. Then there's the Layout Grid plugin, which uses a responsive 12 column grid system.

Common across them all are a few UI challenges:

• For complete 100% flexibility, we would likely need resize handles on each block for positioning, and we’d need to visually surface a grid so you could see what you would snap to. Layout grid does this, but on the downside is locked to the pretty rigid standard 12 column layout.
• That rigid layout we saw as a benefit at the time. But as our layout tools have improved, and mainly as approaches to responsive have changed (intrinsic behaviors are preferred over breakpoint editing), that rigidity turned into an obstacle moreso than a benefit. That is, while it should be possible to edit grids at the standard mobile/tablet/desktop breakpoints, a column based grid layout would be totally dependant on presets for each of these, as opposed to organically and intrinsically responsive behaviors. That might not be the best default experience, layout wise.
• Surfacing snapping points in a global manner is still a really cool concept and idea, and I know that @talldan has explored this for image block resizing. This can be all the trickier to visualize for grids, however, as depending on a cell configuration, it might expand or collapse based on content inside. So if the visualization grid is a separate layer shown above or below the content (as it is in the Layout Grid plugin), this would easily go out of sync if the content isn't also duplicated, making this a rabbit hole to get right.

The above is mostly an attempt at summarizing what's been tried, in hopes of informing next steps. The main take-away is that it seems useful to start with the smallest feasible step that can be useful on its own, and see where that leads. Kind of similar to how the Row and Stack blocks were slowly grew in featuresets, becoming essential in the process.

Would a good starting point be to see if we could bring some smarter intrinsic responsiveness to the Columns block, perhaps slowly refactor it? I know Andrew has tackled this in the past. A starting point could be using grid-template-columns to bring better intrinsic responsiveness (see "Cards" example here). We could potentially keep the existing columns markup as-is, but apply the new system when "Stack on mobile" is toggled?

[andrewserong]

Thanks for adding all the history and extra context @jasmussen!

Would a good starting point be to see if we could bring some smarter intrinsic responsiveness to the Columns block, perhaps slowly refactor it?

I was wondering if the Post Template block might be a good candidate as a starting point (https://github.com/WordPress/gutenberg/issues/44557), since it's potentially a little simpler in that it doesn't have individual column blocks that can set their own width (I think @tellthemachines might have flagged it previously, too). So, it's likely a good one for exploring the intrinsic design approach of automatically expanding/contracting the column size to fit the available space. I'd also be curious if a min-width control would be useful to define a base width for children, a little bit like how we have the minimum font size in fluid typography 🤔

[tellthemachines]

Thanks for the context @jasmussen !

Would a good starting point be to see if we could bring some smarter intrinsic responsiveness to the Columns block, perhaps slowly refactor it?

It would be great to add an intrinsically responsive option to Columns, but the "Cards" example only works if all the columns are of equal width, so we can't combine that behaviour with the variously-sized columns we have currently. It could work as an "auto-columns" toggle where you'd lose access to the column width controls if it was toggled on?

I was wondering if the Post Template block might be a good candidate as a starting point

This is what I'm thinking, yes!

I'd also be curious if a min-width control would be useful to define a base width for children

I think it would be useful to have that, though we can define a sensible default in core to start with. Ideally we have a grid layout that Just Works when enabled, and then folks can fine-tune it if they like with some further controls.

[jasmussen]

It would be great to add an intrinsically responsive option to Columns, but the "Cards" example only works if all the columns are of equal width, so we can't combine that behaviour with the variously-sized columns we have currently. It could work as an "auto-columns" toggle where you'd lose access to the column width controls if it was toggled on?

Great catch. Note that the codepen linked does have a variable width column stacking behavior, though it feels a bit hacky so I'm sharing that only in case it inspires a different approach to this specific problem.

This is what I'm thinking, yes!

I'll refer to you, but that might work yes.

I think it would be useful to have that, though we can define a sensible default in core to start with. Ideally we have a grid layout that Just Works when enabled, and then folks can fine-tune it if they like with some further controls.

Min/max-width control (perhaps as a fancy singular new control) could be useful, yes, though it would be nice to start with a good default, so that it can work without any control, and work for people who don't care about the control (the Just Works part). Consider also here whether any such min/max values could be extracted as global variables, so general responsive properties could perhaps be configured in global styles. I imagine having the style book open while tweaking generalized intrinsic responsiveness behaviors might be a good user experience. What do you think?

[jasmussen]

Speaking of min/max width controls, https://utopia.fyi/ looks beautiful.

[tellthemachines]

Note that the codepen linked does have a variable width column stacking behavior, though it feels a bit hacky so I'm sharing that only in case it inspires a different approach to this specific problem.

That's an interesting approach, though it could only translate to allowing child blocks to span x amount of grid columns; we can't make it work with specific widths like the current Column block does.

Consider also here whether any such min/max values could be extracted as global variables, so general responsive properties could perhaps be configured in global styles. I imagine having the style book open while tweaking generalized intrinsic responsiveness behaviors might be a good user experience.

Oooh you mean something like "min (or max) block width", and it would apply to all blocks? That could be useful.

[jasmussen]

Oooh you mean something like "min (or max) block width", and it would apply to all blocks? That could be useful.

Essentiall a global variable for min. or max. width values. These variables would be the default values, leveraged if you don't customize them on the per-block basis.

Kind of like right now we have a sort of locked-in "mobile" breakpoint at 600px — it would've been nice if that breakpoint was editable in Global Styles.

But to be quite clear, I don't know if such a global value for min/max width properties is useful, so it would not be something to optimize for. Mainly an idea or question at this point.

[SaxonF]

https://user-images.githubusercontent.com/1072756/221087310-cc2c00d5-6c51-4380-afeb-e568329bf7a9.mp4

I've spent some time tinkering with what a more advanced layout experience might look like on WordPress. Would it be possible to merge the columns and group/row blocks? How can we properly cater to advanced users but also keep non technical users happy? Layout is split across the group/row/stack block and the columns block at the moment. Could we simplify and merge into one?

Much easier to experiment in code rather than Figma so i've spun up a sandbox we can play with. Check out the video for a walkthrough.

Codesandbox preview https://flcluv.csb.app/

Edit/fork sandbox https://codesandbox.io/s/sad-euler-flcluv?file=/src/Section.js

[paaljoachim]

I really like your amazing grid layout example @SaxonF

Having an icon toggle between standard canvas and grid canvas would be amazing. One would then need to be able to switch back and forth between the two different layout types.

The grid makes me also think of how tables somewhat worked some time ago. Adding a grid/cells. Being able to add another cell, remove a cell or merge cells. Color the background of cells.

The grid would make it possible to create layouts one would usually create in an Indesign type of program. Giving a really nice flexibility.

Thanks for creating the video showing the grid layout you made! It was very helpful and inspiring!

[robglidden]

I'd like first a fully-functional grid block into which I can just add any number of grid-item blocks.

Like the row block, but with only inner grid-item blocks (that themselves contain inner blocks).

That can then be constrained to simpler variants, patterns, and use cases, like other blocks do.

To style: configure (or select) the css-grid properties on the corresponding blocks.

I note that grid-template-columns and grid-template-areas are not mutually exclusive. It is just that some design approaches may favor one. So no need or benefit to separate.

Also, intrinsive and responsive are not mutually exclusive, nor intended to be. Grid works great with responsive.

I understand this is a different design center than the Layout Grid plugin et al.

But to me it is more user-intuitive, flexible and in line with css grid itself and how it is useful.

React supports the style tag, so when I have added css-grid in it to a custom block it works in the editor.

[robglidden]

When I think of a core CSS grid block, I think of something easy to use, like a row block with more layout options:

And a panel for designers to make and save layouts for users to use:

Boiled down, CSS grids are basically 10 properties:

• grid-template-columns/rows/areas
• grid-auto-columns/rows/flow
• row/column-gap
• grid-column/row

Helps to separate the UI into 3 scenarios - using, designing, and sharing/locking.