{"id":375278,"date":"2022-11-30T06:11:10","date_gmt":"2022-11-30T14:11:10","guid":{"rendered":"https:\/\/css-tricks.com\/?p=375278"},"modified":"2022-11-30T06:11:11","modified_gmt":"2022-11-30T14:11:11","slug":"using-the-new-constrained-layout-in-wordpress-block-themes","status":"publish","type":"post","link":"https:\/\/css-tricks.com\/using-the-new-constrained-layout-in-wordpress-block-themes\/","title":{"rendered":"Using The New Constrained Layout In WordPress Block Themes"},"content":{"rendered":"\n

One of the main goals of the WordPress Site Editor (and, yes, that is now the \u201cofficial\u201d name<\/a>) is to move basic block styling from<\/a> CSS to structured JSON<\/a>. JSON files are machine-readable, which makes it consumable by the JavaScript-based Site Editor for configuring a theme\u2019s global styles directly in WordPress.<\/p>\n\n\n\n

It\u2019s not all the way there yet! If we look at the Twenty Twenty-Two (TT2) default theme, there were two main unresolved issues: styling interactions<\/a> (like :hover<\/code>, :active<\/code>, :focus<\/code>), and the margins<\/a> and padding of layout containers<\/a>. You can see how those were temporarily fixed in the TT2 style.css<\/code> file rather than making it into the theme.json<\/code> file.<\/p>\n\n\n\n

WordPress 6.1<\/a> fixed those issues and what I want to do is look specifically at the latter. Now that we have JSON-ified styles for the margins and padding of layout containers, that opens us up to more flexible and robust ways to define spacing in our theme layouts<\/strong>.<\/p>\n\n\n\n\n\n\n

What kind of spacing are we talking about?<\/h3>\n\n\n

First off, we already have root-level padding<\/strong> which is a fancy way of describing padding on the <body><\/code> element. That\u2019s nice because it ensures consistent spacing on an element that is shared on all pages and posts.<\/p>\n\n\n\n

But there\u2019s more to it because now we have a way for blocks to bypass that padding and align themselves full-width. That\u2019s thanks to padding-aware alignments<\/strong> which is a new opt-in feature in theme.json<\/code>. So, even if you have root-level padding, you can still allow, say, an image (or some other block) to break out and go full-width.<\/p>\n\n\n\n

That gets us to another thing we get: constrained layouts<\/strong>. The idea here is that any blocks nested in the layout respect the layout\u2019s content width \u2014 which is a global setting \u2014 and do not flow outside of it. We can override that behavior on a block-by-block basis with alignments, but we\u2019ll get to that.<\/p>\n\n\n\n

Let\u2019s start with\u2026<\/p>\n\n\n

Root-level padding<\/h3>\n\n\n

Again, this isn\u2019t new. We\u2019ve had the ability to set padding on the <body><\/code> element in theme.json<\/code> since the experimental Gutenberg plugin<\/a> introduced it in version 11.7. We set it on the styles.spacing<\/code> object, where we have margin<\/code> and padding<\/code> objects to define the top, right, bottom, and left spacing on the body:<\/p>\n\n\n\n

{\n  \"version\": 2,\n  \"styles\": {\n    \"spacing\": {\n      \"margin\": {\n        \"top\": \"60px\",\n        \"right\": \"30px\",\n        \"bottom\": \"60px\",\n        \"left\": \"30px\"\n      },\n      \"padding\": {\n        \"top\": \"30px\",\n        \"right\": \"30px\",\n        \"bottom\": \"30px\",\n        \"left\": \"30px\"\n      }\n    }\n  }\n}<\/code><\/pre>\n\n\n\n
This is a global setting. So, if we were to crack open DevTools and inspect the <body><\/code> element, we would see these CSS styles:<\/p>\n\n\n\n
body {\n  margin-top: 60px;\n  margin-right: 30px;\n  margin-bottom: 60px;\n  margin-left: 30px;\n  padding-top: 30px;\n  padding-right: 30px;\n  padding-bottom: 30px;\n  padding-left: 30px;\n}<\/code><\/pre>\n\n\n\n
Cool. But herein lies the issue of how in the world we can allow some blocks to break out of that spacing to fill the full screen, edge-to-edge. That\u2019s why the spacing is there, right? It helps prevent that from happening!<\/p>\n\n\n\n
But there are indeed plenty of cases where you might want to break out of that spacing on a one-off instance when working in the Block Editor. Say we plop an Image block on a page and we want it to go full-width while the rest of the content respects the root-level padding?<\/p>\n\n\n\n
Enter\u2026<\/p>\n\n\n
Padding-aware alignments<\/h3>\n\n\n
While attempting to create the first default WordPress theme that defines all styles in the theme.json<\/code> file, lead designer Kjell Reigstad illustrates the challenging aspects of breaking out of root-level padding in this GitHub issue<\/a>.<\/p>\n\n\n\n
\"\"
Root-level padding prevents blocks from taking up the full viewport width (left). But with padding-aware alignments, some blocks can \u201copt-out\u201d of that spacing and take up the full viewport width (right). (Image credit: Kjell Reigstad<\/a>)<\/figcaption><\/figure>\n\n\n\n
New features in WordPress 6.1 were created to address this issue. Let\u2019s dig into those next.<\/p>\n\n\n
useRootPaddingAwareAlignments<\/code><\/h4>\n\n\n
A new useRootPaddingAwareAlignments<\/code> property was created to address the problem. It was actually first introduced in the Gutenberg plugin v13.8. The original pull request<\/a> is a nice primer on how it works.<\/p>\n\n\n\n
{\n  \"version\": 2,\n  \"settings\": {\n    \"appearanceTools\": true,\n    \"useRootPaddingAwareAlignments\": true,\n    \/\/ etc.\n  },<\/code><\/pre>\n\n\n\n
Right off the bat, notice that this is a feature we have to opt into. The property is set to false<\/code> by default and we have to explicitly set it to true<\/code> in order to enable it. Also notice that we have appearanceTools<\/code> set to true<\/code> as well. That opts us into UI controls<\/a> in the Site Editor for styling borders, link colors, typography, and, yes, spacing which includes margin and padding.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Setting appearanceTools<\/code> set to true<\/code> automatically opts blocks into margin and padding<\/a> without having to set either settings.spacing.padding<\/code> or setting.spacing.margin<\/code> to true<\/code>.<\/p>\n\n\n\n
When we do enable useRootPaddingAwareAlignments<\/code>, we are provided with custom properties with root padding values that are set on the <body><\/code> element on the front end. Interestingly, it also applies the padding to the .editor-styles-wrapper<\/code> class so the spacing is displayed when working in the back-end Block Editor. Pretty cool!<\/p>\n\n\n\n
I was able to confirm those CSS custom properties in DevTools while digging around.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Enabling useRootPaddingAwareAlignments<\/code> also applies left and right padding to any block that supports the \u201ccontent\u201d width and \u201cwide\u201d width values in the Global Styles image above. We can also define those values in theme.json<\/code>:<\/p>\n\n\n\n
{\n  \"version\": 2,\n  \"settings\": {\n    \"layout\": {\n      \"contentSize\": \"640px\",\n      \"wideSize\": \"1000px\"\n    }\n  }\n}<\/code><\/pre>\n\n\n\n
If the Global Styles settings are different than what is defined in theme.json<\/code>, then the Global Styles take precedence. You can learn all about managing block theme styles in my last article<\/a>.<\/p>\n\n\n\n