WordPress 6.1 brings considerable more flexibility to the layout controls and features to the block Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor. A new layout type, “constrained”, was added to the already available Flow and Flex layouts types. In addition, layout refactor efforts bring new layout styles, new block level spacing, more semantic class name for layouts, root padding and a method to disable all layout styles all together for themes.
New “constrained” layout type
The new “constrained” layout type has been split out from the “flow” layout. This means that the “flow” now corresponds only to the base layout configuration. This change moves the content width logic to a new layout type, called “constrained” which makes it easier to set blocks to use content width by default.
What styles does each layout type output?
Flow layout
- Spacing between child blocks with
margin-block-start, margin-block-end;
- Left, right and center alignments for child blocks.
Constrained layout
- Spacing between child blocks with
margin-block-start, margin-block-end;
- Left, right and center alignments for child blocks;
- Width constraints for child blocks (based on settings > layout > contentSize and settings > layout > wideSize from theme.json JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML.);
- Optionally, left/right/center justification for all child blocks.
Flex layout (unchanged)
- Base flex display rules, defaulting to a horizontal orientation;
- Spacing between child blocks with
gap;
- Optionally, left/right/center/space-between justification and horizontal/vertical orientation.
Layout block support refactor
In 6.1, the Layout block support, which powers layout styles for blocks such as Group, Buttons, Social icons, and Columns, has been refactored. Prior to this release, the layout block support would output layout styles at render time for each, and every instance of a block stored in post content or in templates, resulting in redundant styles being output on a site’s frontend as reported in this Gutenberg issue #41434.
To address this, the refactor added the concept of base layout styles by storing a set of layout definitions in the core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. WordPress theme.json file, that contain the default rules for each of the current layout types. These base layout styles are attached to each of the layout types via a semantic class name with the prefix is-layout-, resulting in the following class name-based rules:
is-layout-flow (base layout rules associated with the Flow layout used in the Group and other container block)is-layout-constrained (base layout rules associated with the Constrained layout type used in Group and other container blocks that set content and wide sizes)- i
s-layout-flex (base layout rules associated with the Flex layout type, used in the Buttons, Social Icons, and Columns blocks)
Now, when a block that uses the layout support is rendered, one of the above class names will be injected into the block’s output, attaching the base layout styles to that block. The result is that the layout support will now only output a wp-container-123 classname (where 123 is a semi-random number), and associated styles when a block uses non-default layout attributes. This means a substantial reduction in redundant CSS Cascading Style Sheets. rules for posts or pages containing many Group blocks using the default layout settings.
In addition, when the Layout support outputs the wp-container-123 rules, they are enqueued via the newly added style engine functions, so that all the rules are grouped together in the one style tag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) for output. This further tidies up the CSS output.
Block spacing enabled at the block level in theme.json
A byproduct of the layout refactor is that blockGap can now be set at the block level in theme.json and via the global styles UI User interface, as gap styles are now also output via the above layout type class names, using direct CSS values, instead of the blockGap CSS variable --wp--style--block-gap. For backwards compatibility with themes and blocks that rely on the CSS variable, the value defined for the root styles.spacing.blockGap style is also output as a CSS property.
Note: The Gallery block currently does not support blockGap styles in theme.json as it relies on an ad-hoc approach to gap spacing to factor in widths of the image blocks.
Semantic class names in Layout support
Since WordPress 6.0, the Layout support outputs semantic class names for the layout properties orientation, justifyContent, and flexWrap, resulting in class names such as is-vertical, is-content-justification-left, and is-nowrap.
With the changes in WordPress 6.1, combined with layout type-based class names, it is now possible to target a particular configuration of the Group block, e.g., the Stack variation via a rule such as .wp-block-group.is-layout-flex.is-vertical.
These semantic class names are only output for Layout properties that have been explicitly set.
Root padding
By default, root padding, which can be set in Styles > Layout > Padding, is applied to the outermost wrapper element. On the front end that’s wp-site-blocks; in the editor it’s editor-styles-wrapper.
The problem with this approach is that it doesn’t allow for blocks to expand to full viewport width.
useRootPaddingAwareAlignments changes where left and right padding are applied, so that blocks set to full width can actually span the full viewport width.
How does it work?
Instead of the wrapper, left and right padding are added to the outermost container block that has a constrained layout set. Then, negative margins of the same value are added to any full width children of that block. Additionally, non-full width children of those full width blocks will also have left and right padding applied to them. This is so that the contents of a full width container block don’t bump against the sides of the viewport.
To enable this setting, in theme.json, add "useRootPaddingAwareAlignments": true inside the settings object.
More background in Gutenberg ticket #42085.
Disable layout styles theme support
By default, WordPress outputs structural layout styles for blocks such as Group, Columns, Social icons and Buttons, as part of the layout block support. Until this point, some themes have been opting out of the generated base layout styles by using an undocumented approach of overriding or removing the render_layout_support_flag callback on the render_block filter.
In WordPress 6.1, base layout styles have been consolidated as part of global styles output, so the existing approach of opting out of generated layout styles will no longer work. In its place, themes can now use a new theme support flag, called disable-layout-styles. Themes can opt-in to this feature using the following code:
// Opt in to remove layout styles.
add_theme_support( 'disable-layout-styles' );
Using this new theme support flag ensures that the expected behavior is handled explicitly in code. It also allows themes that use this flag to still make use of semantic class names that are injected into layout blocks at render time, such as content justification classes.
Note: Opting into this feature will remove required styles for blocks such as Group, Columns, Social icons and Buttons, so themes that use this feature will need to supply their own structural layout styles in order for these blocks to render correctly in the editor and on the site’s frontend.
In most cases, particularly for blocks-based themes, the generated layout styles are preferable for ensuring the correct rendering of core blocks. For themes that are looking to adjust block spacing, view the handbook entry for “What is blockGap and how can I use it?”.
For more detail: Documentation > Block Editor > Explanation > Architecture > Layout styles
Props to @andrewserong for co-editing, @bph and @webcommsat for review
#6-1, #dev-notes, #dev-notes-6-1
