Block spacing/layout/is-layout-flow: Top margin also added inside flex items #49914
Comments
jasmussen
added
[Type] Bug
|
@tellthemachines do you have any insights here? Thank you for looking. |
|
Hmm, not sure what's happening there. I can't reproduce it with the test markup on TT3 or Empty theme. This is what I see:
The rule that removes the top margin from the first element should be specific enough to work anywhere: |
|
We could use a unified "let's improve labels-only mode" ticket where we can track some of the possible improvements that surface here and there. For me the one that keeps coming up is when we're using the tooltip for the label, causing it to be very very long. For example, "Apply duotone filter" should just be "Duotone". |
Yes, I'm not sure what's going on here. I'm testing, and previewing in the post editor, using a variation of the TT3 theme. But testing now, I'm also seeing it in the site editor:
Here's the CSS that takes:
I'm seeing a
But that's not the same CSS as you are showing a screenshot of here, I'm seeing the following:
I can also confirm that if I manually add the CSS you have in your screenshot, it's working for me:
So for whatever reason the CSS isn't output for me 🤔 |
|
is it possible that for some reason that block wrapper isn't the first child of its parent? |
|
That was my first instinct, but it doesn't seem to be the case unless I'm doing something wrong. Here a gif showing how I set the margin on every first child inside each column to zero in order for it to take:
Here's the dom, which also looks like the first child rule should be present:
|
|
I'm not quite sure what's happening here as I can't reproduce it locally. From the total absence of the To help debug, could you share the content of the style tag where the main style is coming from? By clicking on <style> in the upper right corner here:
|
|
Sure, here you go. This is from the editor, to be clear, not that it should necessarily diverge too much: Code snippet |
|
Interesting. From the output, it looks like the logic for style generation in the theme.json class is up to date, but the definitions coming from the core theme.json file are from a previous version. If that's the case though, I don't understand why there are 3 rules for flow layout instead of 2: Could your dev env by any chance be running on an older WP version? The caching issue from #45713 should have been fixed in 6.2. |
|
Here's a screenshot of my updates page, I should be on a clean 6.2:
I'm running the trunk GB plugin, and using Local to run the environment. In case it helps, here's the theme I'm using, which is built using the site editor and Create Block Theme, from a TT3 base: Edit: I'm also happy to beta test nightly WordPress variants if that's helpful. I can update to latest nightly, just let me know. |
|
Oooooh I see, the culprit is that theme's theme.json file. It has a |
|
Interesting, so it seems the issue here is either from the theme, or from Create Block Theme, as at no point have I manually edited the theme.json. @matiasbenedetto would you be able to look at this and see where it might come from? Here's the pertinent bit: It scares me a little that those definitions exist, and are actively causing a regression since they are overriding the core block styles. I'm lacking some of the technical foundations, but what is the role of these definitions? And why might a theme want to add them? Thanks so much for the help debugging! |
|
I believe these layout definitions are from the Gutenberg default theme.json, which Create Block Theme will use unless they are overwritten when the sources are merged ( There's an open issue here with a bit more discussion: WordPress/create-block-theme#324. |
|
Seems like we want to omit those from the theme itself, otherwise it can't inherit them from Gutenberg, with the bugfixes we might make to the block editor in tow. |
Yes, the definitions should only ever be in the core theme.json, as they are used to build the core styles for each layout type. They shouldn't be in theme files at all. Are we good to close this issue now? |
Yes! Thank you for all the debugging help, it went above and beyond. |
|
Just sharing the following just in case some people encounter the same problem. |
When a container block has "flow" layout, its innerblocks are subject to this CSS:
There seems to be missing something like this, or at least in the use case I'm about to describe, it's not taking hold:
What I'm seeing is that when using any block inside a columns block, top margin is applied to the first block inside. Take the following example
That's 3 columns with background colors, and a "Test" Cover block in the 3rd column. As you can see there's top margin applied there, when there shouldn't be:
I can zero that out using the margin tool on the cover, but I shouldn't have to. The first block in a stack should not have top margin.
Example code:
The text was updated successfully, but these errors were encountered: