This issue will track experimentation, discussion and other output in relation to the extension of Gutenberg's layout capabilities.

Prerequisites

There are some outstanding issues with the current layout implementation we should address as a priority:

• Show "group" and variations (Row, Stack) in multi-select toolbar #34461
• Editor text has no default left/right margin unless theme opts into site-wide padding  #35884
• Layout blockGap / spacing: Add support for gap set at the block level in theme.json and global styles #39789
• (Possibly) Consider a root-level site padding solution that still lets some items go full-width #35607
• Please add a way to not delete wp-block-group__inner-container when using theme.json. #41124 (ensure a smoother transition to using theme.json for classic themes)
• Gap on columns block is hard-coded with a fixed value #41431 — let's offer an opt-out for styles, separate from classes, also see if we can ensure that fallback gap styles have an appropriately low(ish) level of specificity so that fallback styles can be easily overridden if need be.

The direction

Blocks may opt into Gutenberg’s experimental layout API through their individual block.json files, for example:

"__experimentalLayout": {
    "allowSwitching": false,
    "allowInheriting": false,
    "allowEditing": false,
    "default": {
        "type": "flex",
	"flexWrap": "nowrap"
    }
}

There are presently two layouts: flex and flow. The aim of this tracking issue is to explore approaches that will open up the ability to add and control advanced layouts with blocks that go beyond the block gap, or margin/padding controls.

In #33687 a"layout" is defined as:

a configuration you apply to a container block that changes how its inner blocks are aligned, and also impacts the behavior of these inner blocks (enable/disable some customization options).

The corresponding UI objective is to allow users to choose between a set of layouts and related options in the editor.

Current layout related PRs, issues and other background context

• Layout: Use semantic classnames, centralize layout definitions, reduce duplication, and fix blockGap in theme.json #40875
• Flex Layout Iterations #33687
• Alternative approach to the layout outer padding #36214
• More Block Tools and APIs for container blocks. #27324
• Extract common layout styles #35867
• Global Styles: Make the default layout work as a preset. #36944
• Suggestion: Simplify the layout concept #36082
• Consider a root-level site padding solution that still lets some items go full-width #35607
• Styles: audit utility classes generated on the frontend #41993
• External stylesheets can't override inline core styles #40159

Earlier layout related drafts, experiments and WIPs

• [Try]: Style Engine: Alternative approach to rendering common layout styles from presets #39374
• Try to render flex layout styles as presets #39708

Future layout possibilities:

• Add text indentation support at paragraph block type level #37462
• Fixed Position Header and Footer Template Parts #30121

Future layout WIPs and experiments:

• [WIP] Try: Add sticky position support for the Group block #38039

Why?

Gutenberg should widen the availability of default (and robust) layout options so that users can structure their sites in various ways.

Rather than provide a panacea for every layout problem, we could offer common patterns that appear, and have proved successful, in modern websites.

It would be preferable to provide an extensible system through which we could add future layouts as well.

Current work

There has been some preliminary discussion around how to refactor existing, and integrate new, layouts into Gutenberg in #38974. That discussion has since evolved into a proposal for a refactor of how the Layout support works in: #40875

So far, the work has been to target the current layout implementation and focussing on the means to register and output styles, while trying to take into account contemporary ideas and explorations surrounding the Style Engine.

The plates are still up in the air and spinning, but some concepts that folks are trying (or will have to try) to reconcile include:

1. compatibility: layout rules should be portable across themes, and work well in modern devices/browsers
2. theme.json schema: theme authors should be able to use JSON to determine the layout of their site and blocks.
3. nomenclature: how layouts will "identify" themselves to the application and in the rendered content, their property names, element classnames and modifiers

What’s next (short term)

Continuation of the experimentation and research phase

With the following goals:

• Standardize styles and classname generation for the layout support, reduce style duplication
• General research, read Every Layouts and, if relevant, examine CSS design systems for inspiration
• Experimentation, for example, what it would take to introduce many of the layouts from
• Implement and test extensibility
• Test backwards compatibility
• Document findings
• Define incremental tasks.

A further line of inquiry is to research how to provide layout options at the root and inner block level, that is, applying "layout" to a blocks container element (and therefore immediate first-level descendants) and targeting specific inner block "containers".

The relevance of the Style Engine

Integral to the refactor and addition of layout styles to Gutenberg is the Style Engine, which has thus far a few stated goals and many more hopes pinned upon it.

A distilled statement of these goals and hopes might be “to offer a consistent API for generating classnames and rendering CSS for blocks”.

In the context of layouts (and beyond), a centralized way to generate lean, consistent CSS and classnames is important to:

• Reduce duplication of code, and maximize cacheability
• Ensure internal and external uniformity and predictability.

One potential path forward is to explore centralising base layout styles output in global styles, and use a centralised set of definitions for the various layout types. This is being explored in #40875.

TODO

This is a short-list attempting to capture some incremental steps toward a centralised approach for outputting layout styles, instead of layout styles being applied one-at-a-time when each individual block is rendered.

• Land on an approach for consolidating how layout styles are being output, and how to go about outputting semantic classnames, along with reducing reliance upon container class ids and individual style tags. (Merged in #40875).
• Remove body prefix from Layout rules output (suggested in this comment)
• Follow up on the work in Add utility classnames back to blocks that have layout attributes specified #41487 and implement styles that are output to match the semantic classnames (address Global Styles: Make the default layout work as a preset. #36944, further improve Group block's generated CSS are redundant. #41434, and close out Explore options to add back semantic classnames to block wrappers  #38719). Part of this work should factor in issues such as the one raised in Query Pagination: Correctly position the "next" link on the first page. #42764 (comment) where certain values should not be available depending on the orientation (e.g. space-between should not be available in vertical orientation?)
• Add axial support in global styles for blockGap where it's opted in at the block level (suggested in this comment)
• Add blockGap control in root dimensions panel in global styles.
• Look into options for themes to explicitly opt out of Layout styles (including base layout styles) and Layout classnames (based on this discussion). This should resolve issues like (Gap on columns block is hard-coded with a fixed value #41431) — merged in Layout: Add a disable-layout-styles theme supports flag to opt out of all layout styles #42544
• Follow-up to disable-layout-styles support flag, to explore whether or not we should prevent UI controls from being displayed that have no reachable output when the styles are disabled (e.g. custom content sizes). This was raised in this comment.
• Once a stable API is in place for how layouts work and how classnames are output, explore how plugins and themes can augment or filter how classnames are generated (implement the feedback in Add utility classnames back to blocks that have layout attributes specified wordpress-develop#2840 (comment)).
• The layout support should hopefully be in a good place for additional layout types to be added.