This is the related issue for this PR: #35607

Wildly fast and impressive as usual. Question: where in theme.json do I add the "outerPadding" value?

(Edit: I tried adding it as settings.layout.outerPadding, but can't seem to get that to work)

Size Change: +2.38 kB (0%)

Total Size: 1.07 MB

_{compressed-size-action}

settings.layout.outerPadding that should be right. (see the linked 2022 PR), it does work for me 🤷‍♂️ but let me check again.

Yeah I'm not seeing the --wp-style-layout-outer-padding variable output. I'm probably doing something wrong, I'll keep digging. But just by glancing at the code, this was exactly what I had been hoping for.

I'm testing this again with my alignments markup on emptytheme.

The first thing I see is that this requires the group blocks to have inherit layout. In the case of emptytheme the template parts for example are defined simply with

<!-- wp:template-part {"slug":"header","tagName":"header"} /-->

and no other group blocks inside, and there's no padding being applied to it. I suppose that's fine and it's easy to circumvent, I just wasn't expecting that.

Looking at the mobile version I see a little issue:

Trunk	This PR

When I debug this I see that for example something like:

<!-- wp:cover {"customOverlayColor":"#b65454","align":"full"} -->
<div class="wp-block-cover alignfull"><span aria-hidden="true" class="has-background-dim-100 wp-block-cover__gradient-background has-background-dim" style="background-color:#b65454"></span><div class="wp-block-cover__inner-container"><!-- wp:paragraph {"align":"center","placeholder":"Write title…"} -->
<p class="has-text-align-center">Test cover block that is full width</p>
<!-- /wp:paragraph --></div></div>
<!-- /wp:cover -->

Is failing like so:

We've encountered this case before and solved it using width: unset; for these cases

Yeah I'm not seeing the --wp-style-layout-outer-padding variable output. I'm probably doing something wrong, I'll keep digging. But just by glancing at the code, this was exactly what I had been hoping for.

		"layout": {
			"contentSize": "840px",
			"wideSize": "1100px",
			"outerPadding": "30px"
		}

Worked for me while testing with emptytheme. You need to look for the variable on the containers with inherit layout, it's not being applied to the root container.

The first thing I see is that this requires the group blocks to have inherit layout.

If the group block doesn't have any layout (inherit or a specific one), the inner blocks won't have full width options available anyway.

You need to look for the variable on the containers with inherit layout, it's not being applied to the root container.

Thanks, I see it! Works well:

This seems to make sense to me, and work as intended, but let me poke at it a bit more!

For the "Cover" block, there's a "width: 100%" rule in the default styles there. I wonder why we have it and whether we can remove it or transform it to min-width. Theme authors shouldn't have to unset it on their own.

For the "Cover" block, there's a "width: 100%" rule in the default styles there. I wonder why we have it and whether we can remove it or transform it to min-width. Theme authors shouldn't have to unset it on their own.

Yep, can confirm min-width would solve it for the cover block! I tested a bunch of other blocks that did fine on full width:

I removed the width rule from the cover block. I didn't see any issue but yeah more testing would be good.

I removed the width rule from the cover block. I didn't see any issue but yeah more testing would be good.

Agree, I looked for the reason we have it there and I couldn't find it, it's been years and the code has changed a bit, with display: flex; on the block I don't think we need it and I couldn't break it without the width value.

I like it.

• When embracing inherited layout, you can essentially control which blocks get these rules. That's a nice and simple way to ensure a generic approach to this
• With a single outer padding value, we can create an interface to adjust it in global styles, that same as "blockGap" will feel nice and intuitive to use
• Without extra burden on themes, full wide blocks are truly full wide, and break beyond the site padding, as envisioned.
• Groups, including wide and fullwide inside, they work as you'd expect, still with the "inherit" toggle.

It will need a bit of understanding of what the "inherit" toggle does, we might need to refine the help text a little bit, but I think this is a good thing overall.

The one thing I'm still scratching my head over is the top and bottom paddings. By zeroing them out we enable the patterns where topmost (or last) blocks can go all the way to the top, which for instance is needed in TT2. I'd love to avoid difficult first-child rules that add negative top margin to handle this, but at the same time it feels like we need a simple and intuitive way to allow top padding.

I'll think about this a bit more over lunch, but just as a quick option: can we allow axial controls in theme.json? I.e. TT2 can add:

"layout": {
	"contentSize": ...,
	"wideSize": ...,
	"outerPadding": "0 1.25rem"
},

that would enable the specific TT2 patterns to go all the way to the top, and handle any extra top padding inside its own header template part. But other themes could simply add this:

"layout": {
	"contentSize": ...,
	"wideSize": ...,
	"outerPadding": "1.25rem"
},

to have a uniform all the way around padding. This would allow them to have easy true fullwide images in their posts, but a simple padding all the way around.

I'll come back to this.

I think the outerPadding format should be the exact same format used for the "padding" attribute when you specify a padding for a block. The layout should be smart enough to extract the left and right ones from there and apply them to the full widths.

This is cool! It generally seems to work well, and I like having access to this as a variable.

A couple questions:

• Would this live alongside the current site padding control? Or replace it?
• If a group block has a background color + alignfull, would it make sense to swap out the default padding value here with the new --wp-style-layout-outer-padding variable? This would ensure that text in has the same outer padding as the rest of the page. Currently nested alignfull group blocks inherit this incorrect padding.

I'm also seeing one scenario that introduces some breakage: setting padding on a wide-width group block.

<!-- wp:group {"align":"wide","style":{"spacing":{"padding":{"top":"50px","right":"50px","bottom":"50px","left":"50px"}}},"backgroundColor":"secondary","layout":{"inherit":true}} -->
<div class="wp-block-group alignwide has-secondary-background-color has-background" style="padding-top:50px;padding-right:50px;padding-bottom:50px;padding-left:50px"><!-- wp:paragraph -->
<p>Wide width</p>
<!-- /wp:paragraph -->

<!-- wp:group {"align":"full","backgroundColor":"foreground","textColor":"background"} -->
<div class="wp-block-group alignfull has-background-color has-foreground-background-color has-text-color has-background"><!-- wp:paragraph -->
<p>Full width</p>
<!-- /wp:paragraph --></div>
<!-- /wp:group --></div>
<!-- /wp:group -->

I updated the format of the outer padding to support any kind of padding (object with left, right, top, bottom keys like the padding attribute).

If a group block has a background color + alignfull, would it make sense to swap out the default padding value here with the new --wp-style-layout-outer-padding variable?

Maybe but this would require a number of things: update it for all blocks and not just "group", provide a fallback for classic themes, it might not be so simple.

Would this live alongside the current site padding control? Or replace it?

This is the only thing that make me concerned about this PR and whether it's the right approach. These two things (outerPadding and padding) are completely different things and in fact one has the potentially to override the other (thus your bug). We can't use padding at the moment because there's no way to "inherit" padding from theme.json like we do for "layout", that's why "outerPadding" is a property of the layout object.

Potential solution here is to introduce some kind of dependency between "layout" and "padding" block supports. Meaning if a block supports both padding and layout and the user chose to "inherit" layout, hide the "padding" control and ignore the value defined by the user there and inherit the one from theme.json instead. Maybe that's the right solution though I'd love more thoughts here, I'm not sure I feel confident making that decision on my one :) cc @mcsf @mtias @ntsekouras

I think the outerPadding format should be the exact same format used for the "padding" attribute when you specify a padding for a block.

That means I can explicitly define a top padding if I want to, correct? (If yes, sounds good!)

Edit: Welp, we posted at the same time. I consider my question answered then! 😄