One of the main goals of the WordPress site editor (now officially named) is to migrate the basic block style from CSS to structured JSON. JSON files are machine readable, which allows JavaScript-based site editors to configure global styles of themes directly in WordPress.
But this work has not been fully completed yet! If we look at the Twenty Twenty-Two (TT2) default theme, there are two main problems that have not been resolved: style interaction (such as: hover,:active,:focus) and margins and padding of the layout container. You can see how these issues are temporarily fixed in TT2's style.css file instead of adding them to the theme.json file.
WordPress 6.1 fixes these issues, and I want to specialize in the latter. Now we have JSON styles for layout container margins and padding, which provides us with a more flexible and powerful way to define spacing in theme layouts .
What kind of spacing are we talking about?root level fill, which is a fancy statement about element fill. This is great because it ensures consistent spacing on elements shared across all pages and posts. But there is more, because now we have a way to get the block to bypass that padding and align it with full width. This is thanks to the Fill-aware alignment, a new optional feature in theme.json. So even if you have root-level padding, you can still allow, for example, an image (or some other block) to break through and display full width.
This reminds us of another thing:Constrained layout. The idea here is that any block nested in the layout obeys the layout's content width (this is a global setting) and does not flow out of that width. We can overwrite this behavior block by block using alignment, but we'll discuss it later.
Let's start with...Root level fill
<code>{
"version": 2,
"styles": {
"spacing": {
"margin": {
"top": "60px",
"right": "30px",
"bottom": "60px",
"left": "30px"
},
"padding": {
"top": "30px",
"right": "30px",
"bottom": "30px",
"left": "30px"
}
}
}
}</code>
<code>body {
margin-top: 60px;
margin-right: 30px;
margin-bottom: 60px;
margin-left: 30px;
padding-top: 30px;
padding-right: 30px;
padding-bottom: 30px;
padding-left: 30px;
}</code>However, when working in a block editor, there are indeed many cases where you may want to break through that spacing in a sexual instance. Suppose we put an image block on the page and we want it to be displayed full width while the rest obeys root-level padding?
Enter...
Lead designer Kjell Reigstad illustrates the challenging aspects of breaking through root-level fill in this GitHub question when trying to create the first default WordPress theme that defines all styles in the theme.json file.
New features in WordPress 6.1 are designed to solve this problem. Let's dig into these things next.
A new useRootPaddingAwareAlignments property was created to solve this problem. It was actually first introduced in Gutenberg plugin v13.8. The original pull request provides a good introduction to how it works.
<code>{
"version": 2,
"styles": {
"spacing": {
"margin": {
"top": "60px",
"right": "30px",
"bottom": "60px",
"left": "30px"
},
"padding": {
"top": "30px",
"right": "30px",
"bottom": "30px",
"left": "30px"
}
}
}
}</code>First of all, it is a feature that we must opt in. This property is set to false by default, and we must explicitly set it to true to enable it. Also note that we have also set appearanceTools to true. This allows us to use UI controls in the site editor to set style borders, link colors, typography, and spacing (including margins and fills).
Set appearanceTools to true automatically makes the block select margins and padding without setting settings.spacing.padding or setting.spacing.margin to true.
When we enable useRootPaddingAwareAlignments, we will get a custom attribute with the root fill value set on the front-end element. Interestingly, it also applies the padding to the .editor-styles-wrapper class to show spacing when working in the backend block editor. Too cool! I was able to confirm these CSS custom properties in DevTools while digging around.
Enable useRootPaddingAwareAlignments also applies left and right fills to any block that supports the "Content" width and "Width" width values in the global style image above. We can also define these values in theme.json:
<code>body {
margin-top: 60px;
margin-right: 30px;
margin-bottom: 60px;
margin-left: 30px;
padding-top: 30px;
padding-right: 30px;
padding-bottom: 30px;
padding-left: 30px;
}</code>If the global style settings are different from those defined in theme.json, the global style takes precedence. You can learn all about managing block theme styles in my previous post.
So the last code example will give us the following CSS:
<code>{
"version": 2,
"settings": {
"appearanceTools": true,
"useRootPaddingAwareAlignments": true,
// etc.
},</code>[id] represents a unique number automatically generated by WordPress.
But guess what else we got? Fully aligned!
<code>{
"version": 2,
"settings": {
"layout": {
"contentSize": "640px",
"wideSize": "1000px"
}
}
}</code>Did you see it? By enabling useRootPaddingAwareAlignments and defining contentSize and wideSize, we also get a fully aligned CSS class for three container configurations that control the block widths added to the page and article.
This applies to the following layout-specific blocks: columns, groups, article content, and query loops.
Suppose we add any of the above layout-specific blocks to the page. When we select a block, the block settings UI will provide new layout settings based on the settings.layout value we define in theme.json (or global style UI). The Internal Block Usage Content Width setting is enabled by default. If we close it, the container has no max-width and the blocks in it will be displayed edge-to-edge.
If we keep the toggle on, the nested block will obey the contentWidth or wideWidth values (more on this later). Alternatively, we can use the numeric input to define custom contentWidth and wideWidth values in this one-time instance. This is a great flexibility!
The settings we just viewed were set on the parent block. Once we nest the block inside and select it, we can use additional options in that block for contentWidth, wideWidth, or full-width display.
Note how WordPress multiplies the root level populated CSS custom attribute by -1 to create a negative margin when the Full Width option is selected.
We just introduced the new spacing and alignment brought by WordPress 6.1. These are specific to blocks and any nested blocks within blocks. But WordPress 6.1 also introduces new layout features to gain greater flexibility and consistency in theme templates.
Example: WordPress completely refactors its Flex and Flow layout types and provides us with a constrained layout type, which makes it easier to align block layouts in the theme using the content width settings in the site editor's global style UI.
Flex, Flow and Constrained Layout
Justin Tadlock provides a broad introduction to different layout types and semantic classes, including use cases and examples.
Update your theme to support constrained layouts
<code>{
"version": 2,
"styles": {
"spacing": {
"margin": {
"top": "60px",
"right": "30px",
"bottom": "60px",
"left": "30px"
},
"padding": {
"top": "30px",
"right": "30px",
"bottom": "30px",
"left": "30px"
}
}
}
}</code>Disable layout style
<code>{
"version": 2,
"styles": {
"spacing": {
"margin": {
"top": "60px",
"right": "30px",
"bottom": "60px",
"left": "30px"
},
"padding": {
"top": "30px",
"right": "30px",
"bottom": "30px",
"left": "30px"
}
}
}
}</code>Here is an important warning: disabling support for default layout types will also remove all basic styles of these layouts. This means you need to style your own style for spacing, alignment, and whatever else you need to display content in different templates and block contexts.
As a big fan of full-width images, the new features include WordPress 6.1 layout and fill-aware alignment are two of my favorite features. Working with other tools, including better margin and fill control, smooth typography, and updated listings and reference blocks, is a testament to a better content creation experience.
Now we have to wait and see how average designers and content creators can use these incredible tools and take them to the next level.
Since the site editor development iteration is underway, we should always anticipate the difficulties of the road ahead. However, as an optimist, I would love to see what happens in the next version of WordPress 6.2. Some things I'm paying close attention to include features that are being considered, support for sticky positioning, new layout class names for the internal block wrapper, updated footer alignment options, and adding constrained and flow layout options to the cover block.
This GitHub issue #44720 lists layout-related discussions planned for WordPress 6.2.
I consulted and referred to many sources while delving into all of this. Here is a huge list of what I found helpful and I think you might also like.
The above is the detailed content of Using The New Constrained Layout In WordPress Block Themes. For more information, please follow other related articles on the PHP Chinese website!
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
