Add outer padding support to the flow layout #35919
Conversation
youknowriad
added
[Type] Enhancement
youknowriad
requested review from
ellatrix,
oandregal,
spacedmonkey and
TimothyBJacobs
as code owners
|
This is the related issue for this PR: #35607 |
lib/block-supports/layout.php
Outdated
| $style = "$selector > * {"; | ||
| $style = "$selector {"; | ||
| $style .= "--wp-style-layout-outer-padding: $outer_padding;"; | ||
| $style .= 'padding: 0 var(--wp-style-layout-outer-padding);'; |
There was a problem hiding this comment.
For simplicity, the outerPadding property is assumed to represent the left/right paddings of the container block. We could potentially update it to support any kind of value but it would require a bit more code.
There was a problem hiding this comment.
I wonder what we can do here. The zero top padding is important for the TT2 patterns, sure, but i imagine in many cases, sites will want a little top and bottom padding:
I'd definitely prefer to avoid gnarly first-child/last-child rules, so this is a head scratcher.
|
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
ℹ️ View Unchanged
|
|
|
|
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
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:
When I debug this I see that for example something like: Is failing like so: We've encountered this case before and solved it using |
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. |
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. |
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 |
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. |
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 |
|
I like it.
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: 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: 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 |
|
This is cool! It generally seems to work well, and I like having access to this as a variable. A couple questions:
I'm also seeing one scenario that introduces some breakage: setting padding on a wide-width group block.
|
|
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).
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.
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 |
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! 😄 |
|
I've been testing this against the themes that we are working with and overall I see everything working as expected. The only exception is still the headers and I don't know if it's because I need to think of other way to handle them with this new implementation. Blockbase here running this PR and these changes to implement it on the theme:
Without both PRs we had padding on the header:
The problem here is that the header markup is like so (we are using flex layout): I'm thinking that the problem here is that we can't apply I can of course apply an explicit padding in the markup but that defeats the purpose of all this, doesn't it? |
|
What are next steps to enable this to land? Anything I/we can help with? |
|
I'm still seeking opinions and thoughts on the second aspect on that comment #35919 (comment) |
|
Currently, if blocks are outside of the "layout: inherit" context then they will default to full width. If we introduce a site level padding then the default behaviour would change in this case. (I don't see this as a problem, just trying to summarize the situation!) Full and wide alignments don't make any sense without "layout: inherit" being set, so it seems fine to connect them to the outerPadding property. The way I see it we should only have one outerPadding variable which would be part of the layout that "layout: inherit" blocks would be aware of - it would sit conceptually at the same level as the "{ layout: { content, wide }}" properties. |
I think that sounds good. I guess you think |
| margin-left: calc( -1 * ${ outerPadding.left || 0 } ) !important; | ||
| margin-right: calc( -1 * ${ outerPadding.right || 0 } ) !important; |
There was a problem hiding this comment.
| margin-left: calc( -1 * ${ outerPadding.left || 0 } ) !important; | |
| margin-right: calc( -1 * ${ outerPadding.right || 0 } ) !important; | |
| margin-left: calc( -1 * ${ outerPadding?.left || 0 } ) !important; | |
| margin-right: calc( -1 * ${ outerPadding?.right || 0 } ) !important; |
Full and wide alignments do make sense without layout: inherit, you can define custom layouts with content sizes for any part of your template.
No, I mean, not applying it at all. |
OK, yes good point, but still the full and wide alignments only make sense when a layout is set, correct? |
yes, a "flow" layout |
|
@youknowriad: Should we merge this for 5.9 or punt? |
|
I'm still uncertain about this, I'm not entirely satisfied with the current solution as I don't want us to duplicate padding in two places. I have potentially an alternative on my mind but not sure I'll have enough time to solve it on time for Tuesday, maybe it's fine to solve this after alpha. |
|
I don't believe much in this PR, I prefer the alternative in #36214 personally so I'm closing this one. |
closes #35607
While implementing the 2022 theme, it has been noticed that full width blocks should ignore the padding of the container block in order to expand to the whole window width.
A solution to this is to use negative margins for full aligned blocks, that said, the solution means that the layout should be aware of the applied padding. This PR solves this by adding a new "outerPadding" config to the "flow" layout.
Testing instructions