Block Library: Column: Add predefined "layout" selections for new Columns block

[aduth]

Previously: #15499
Blocked by: #15662

As of #15499, it is possible to resize a Column block using the "Percentage width" input in the block inspector. Since some layouts may be common, we should consider to present the user a choice amongst a few predefined layouts when first inserting a Columns block.

Prior art:

When inserting a new Row block from the Coblocks plugin, the user is presented to choose both the number and from a number of layout options:

Implementation specifics:

The idea for predefined arrangements of inner blocks may be worth abstracting as a general feature for any block which supports nesting.

Specific proposals for layouts:

• Thirds
• Halves
• Two-thirds, one-third
• ... ? (Feedback welcome in comments)

[kjellr]

👋 I created a handful of icons for these sorts of templates, in both 48px and 24px sizes:

Here they are for when we're ready to try them out:

• ⬇️ Gutenberg Column Layout Icons, 24px
• ⬇️ Gutenberg Column Layout Icons, 48px

The Figma file is here:
https://www.figma.com/file/RP2ibyATAXqdwBuXsROxe08G/Layout-Icons?node-id=0%3A1

I'm working on some comps to think through this flow, and will post later today.

[kjellr]

I'm working on some comps to think through this flow, and will post later today.

Alright, I'm back. 🙂

▶️ Figma Prototype

CoBlocks has users make two choices up front: number of columns and layout. For our placeholder state, I wondered if we can delay the distinction between those until after the block is set up. This way, we can surface a handful of common options up front, and we can get folks into the block quicker:

Once the block is setup, users would be able to adjust the column count and layout in the sidebar. When they adjust the number of columns, the layout options would refresh to match:

[aduth]

CoBlocks has users make two choices up front: number of columns and layout. For our placeholder state, I wondered if we can delay the distinction between those until after the block is set up.

I think it's an important distinction from the implementation perspective as well, whether we need to anticipate support for multi-step wizards, or if it's enough to expect that there'd always be at most one step in choosing a predefined layout option for a block.

[codebymikey]

This is a crucial feature that I think is missing in core.
Columns are the basic foundation of Gutenberg blocks, but the current implementation doesn't play well with sites/themes which work with non-equal column widths.

I don't think it's a good idea to use a third party plugin to support this feature.

It makes more sense to provide a basic set of non-equal widths, but then provide hooks which allows theme developers to specify their own layouts (with icons?).

And then it'd all be added as a custom class (kinda like how block styles are are implemented), allowing designers to easily override the styles.

Who is the best person to speak to regarding this and whether it's something that is willing to be added?

[aduth]

@codebymikey There are a number of Columns enhancements related to resizing (including this one) already opened as issues.

https://github.com/WordPress/gutenberg/issues?q=is%3Aopen+is%3Aissue+label%3A%22%5BBlock%5D+Columns%22

These would be the best place for implementation discussion. You may also plan to join one of the upcoming weekly editor chats.

Resizable columns is already available in the plugin as of #15499 (Gutenberg 5.7).

[codebymikey]

Thanks @aduth, and yeah I noticed the resizable block feature. I liked that it provided a solution for a problem I had, but I think it could be UX could be improved even further, as I don't think it's current implementation is the most user-friendly/flexible (e.g. I would expect all the settings to be inside the Columns block rather than having to select a specific child Column).

I would generally avoid inline styles in blocks when possible and implement everything using classes.
This provides the most flexibility for designers and theme editors e.g. with the inline column widths, it's not going to be responsive, and will require !important rules in order to get it to work responsively.

Giving all editors the ability to set arbitrary widths is just asking for trouble design-wise, and I'd like to avoid that if possible. It would be easier if the theme developer could specify what types of column layouts they wanted to support, and then the appropriate classes were applied and the CSS rules handled the rest.

I'm currently working around this inline attributes issue by creating a custom editor.BlockEdit filter on the Columns block which has a drop-down of custom layouts (e.g. 60/40, 40/60, 30/40/30 e.t.c), when selected adds a custom class on the block. It's not the best, but it works!, so I would love if this was something that came as part of the core plugin.

I followed the editor chat link but couldn't find any info on where the Gutenberg talks took place.

[philbraun]

I would generally avoid inline styles in blocks when possible and implement everything using classes.
This provides the most flexibility for designers and theme editors e.g. with the inline column widths, it's not going to be responsive, and will require !important rules in order to get it to work responsively.

This is even more true because, due to the simplistic "flex-basis:33.33%" style used, the columns don't take the margin into account and thus don't align properly.

Using calc values doesn't get 100% there, but it's a lot closer.

Having classes instead of inline styles would make this much easier and cleaner to override.

[richtabor]

@kjellr Instead of a separate "Layout" control within the Settings Sidebar, could we have the layout selection implemented within the Styles panel? They're essentially styles (variations) of the columns block. Just a thought. :)

Here's how we've implemented a secondary layout selection in CoBlocks:

[kjellr]

Thanks @richtabor! For columns that might make sense, however this "patterns" section will be a reusable component, and will likely be applied to blocks that do already have block styles too. For that reason, I don't think it makes sense to mix them in there. I'm starting to think through how that might work over here, and would love your thoughts once I have some comps posted up: #16283

[greatislander]

I'd like to +1 @codebymikey and @philbraun's comments above. Adding really flexible controls is awesome for some use cases but also makes it hard to enforce project design standards. For example, I'm currently building a Gutenberg-based project which always uses 1/3 | 2/3 two-column layouts. I see two challenges with the way the columns block is moving:

1. As per @philbraun, using inline flex-basis styles makes it hard for theme developers to unregister Gutenberg's styles and use their own (I'm styling columns with CSS grid for my project).
2. The removal of the has-<x>-columns class in Add Columns template options, support InnerBlock templateOptions #16129 makes it doubly impossible to provide alternative styles based on the number of columns in a columns block.

What's the rationale for moving from classes to inline styles? Thanks in advance.

[richtabor]

Just thinking aloud, but perhaps the patterns can be filtered theme-side?

[youknowriad]

This is implemented for the columns now. The patterns discussion should continue in #16283