Block Editor: Implement a responsive grid mode for InnerBlocks and a basic grid block that leverages it.

[epiqueras]

Description

This PR seeks to introduce an experimental responsive grid mode for InnerBlocks. This mode could be used to power a myriad of grid based blocks, where each one tunes the UI to what is most appropriate for each context.

It can be enabled using a new __experimentalGridMode boolean prop on InnerBlocks and InnerBlocks.Content. When enabled, it will render the inner blocks in a responsive, min-width breakpoint based grid layout.

In the editor you can toggle between breakpoints, add, remove, move, and resize blocks, etc. The layouts will be persisted as an attribute of the parent block. In the front end, the saved layouts are rendered using a combination of media queries and CSS grid.

There is a lot more potential for customization that I felt would have made this PR too expansive, but I imagine that in the future we could even support customizing things like the number of columns and the row height, per breakpoint, and even the breakpoints themselves.

It's also worth noting that the interactions are far from perfect, but I think it's usable enough to share now.

The main library used for the editor portion of this PR is a somewhat low level grid editing library used by lots of large projects, like AWS, HubSpot, Monday, etc.

https://github.com/STRML/react-grid-layout#projects-using-react-grid-layout

How has this been tested?

It hasn't been thoroughly tested yet.

Screenshots

https://youtu.be/1CacV2MYF_A

Types of Changes

New Feature: InnerBlocks now supports a grid mode for building grid based layouts and there is a new basic grid block that leverages it.

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.
• I've updated all React Native files affected by any refactorings/renamings in this PR. .

[aristath]

Amazing... I started working on the exact same thing last week 'cause I needed it, it's great to see this in core ❤️ ❤️

The only thing missing from that implementation is the ability to edit the width of columns and height of rows. If that gets implemented too, then this block could be used as a super-block for the site-layout in templates

[epiqueras]

Thanks! 😄

Yeah, that's the idea.

There is a lot more potential for customization that I felt would have made this PR too expansive, but I imagine that in the future we could even support customizing things like the number of columns and the row height, per breakpoint, and even the breakpoints themselves.

[aduth]

A note in passing, as I was testing this very briefly:

I see horizontal scroll in a newly added block:

(Aside: Might help to test with Show scroll bars: Always)

[aristath]

I've been thinking a lot about this one lately...
A "grid" block like this one would be an essential step towards full-site editing. In fact I'd say it's probably the most essential part in allowing theme-developers to start building something really usable.
In order for this to be really useful though, it would have to allow the following:

• Setting the width of grid columns (grid-template-columns). Having everything set to 1fr would not allow for layouts like for example a 300px-wide sidebar, or a side-header that is 20em wide.
• Setting the height of rows (grid-template-rows). This would allow users to define that their header is 200px tall, and it won't grow taller on pages with limited content.
• Multiple grids should be allowed nested. This way they can have a "global" grid with just 3 rows for example, and a separate grid inside the 1st row where they'll be able to build their header (which will usually need things like branding, navigation, search, and whatever else users deem necessary for their specific scenario).

---

STRML is probably the best script I've found so far that can help us achieve these goals, it is used by several large projects and is well-maintained. We could build something custom, but I really can't think of a good reason why we would do something like that instead of using a well-established library.

---

The only thing I question in this implementation is the "responsive" part. "Responsive" doesn't necessarily mean "multiple breakpoints"... Multiple breakpoints will only make it harder for people to build something if they have to do multiple steps. It could be as simple as a single breakpoint (big screen/small screen), switching from display:grid to flex or even block - in which case the blocks become stacked. The "stacked" thing is probably the simplest experience for mobile users where horizontal space is limited. In that case, the only thing that users would have to decide is what the breakpoint for the grid/stacked change will be, or it could be defined in the theme itself.

[epiqueras]

That could be a sensible default, but there are too many screen sizes to limit responsiveness to just that. What if you just want your sidebar to collapse on smaller tablets for example.

[aristath]

There are too many variables for mobile/tablet/desktop... For example my theme may have a native-looking mobile menu on the bottom where the home/menu/search buttons go. That would require a "hide on mobile" switch on each block... adding a switch like that however on blocks because "what if my theme has feature X" would lead to an extremely cluttered UI making things more difficult to edit.
Yes, I may want my sidebar to collapse only on a specific breakpoint.
But now that I think about this, what if the breakpoint was per-grid?
So for example I can define a breakpoint for my global grid (which has the sidebar) @800px, and I can set the breakpoint for my header grid @60em, while I leave the footer breakpoint blank - which will fallback to the theme default.
This way with nested grid users can achieve whatever result they may need. If they want something simple they just don't bother with breakpoints, and it just collapses to stacked on smaller screens. If they want to fine-tune things they can do it on infinite levels by properly structuring their templates and defining breakpoints on their grids.

[epiqueras]

I like that idea. It does simplify things a lot. We would also need an option to completely hide a grid at the breakpoint. For cases where you want to not display sections instead of collapsing them. What do you think?

[aristath]

We would also need an option to completely hide a grid at the breakpoint.
For cases where you want to not display sections instead of collapsing them.

Makes perfect sense 👍

[aristath]

The only thing that troubles me is the technical aspect of this: In order to make breakpoints work like this, all grids should have an ID so they can be targeted by our styles. So in case the user hasn't defined an ID manually, perhaps a unique ID should be generated?
If we have <div class="wp-block-grid" id="foo"> then we'll be able to target it by adding an inline style with something like

<style>
/* 600px is the user-defined breakpoint - or default */
@media screen and (max-width: 600px) {
  /* user chose to hide the grid on mobile */
  #foo { display: none; }
}
</style>

Without an ID or some other unique selector we won't be able to target a specific grid to apply our styles

[epiqueras]

We can generate an ID by hashing the grid’s attributes and its position. I did something similar in this PR.

[aristath]

I just checked out the branch and yeah, you're right, it's all already implemented 👍
I was avoiding git-clone & npm install 'cause I'm on a metered connection and the data cost is huge for these builds. Anyway, I did now so I can check this one more in-depth.
So the real question here now is where do we put the column-width & row-height controls? That is the main UI issue from my perspective... 🤔

[epiqueras]

I think the grid lines should be draggable and maybe show an input on hover for more granularity or for changing units for a specific grid line. The toolbar should also expose a way of setting global options for all row/column grid lines. The placeholder should offer a set of presets to pick from.

[mapk]

If this becomes a way for users to create new templates, as noted as a possibility here: #19254, I'd love to be able to do something like this with it.

I begin laying out the basic structure of the page while planning for template-parts; Header, Content, Footer. I then try adding Sidebars, etc.

These features become a necessity:

1. Add/Remove grid-items.
2. Able to move them around freely without being adjacent to other grid-items.
3. Able to drop them below or above particular rows of grid-items.

The example is from: https://strml.github.io/react-grid-layout/examples/6-dynamic-add-remove.html

[epiqueras]

That can all be done in this implementation.

[epiqueras]

Closing in favor of #20000.

[ockham]

Closing for real, since #18600 (comment) doesn't seem to have done the trick 🙂