Block margin theme.json settings are being overridden

[mikachan]

Description

When margin is applied via theme.json to a site title block, it looks like it's being overridden by the following CSS on the front end:

body .is-layout-flex > * {
    margin: 0;
}

Editor	Front end

Step-by-step reproduction instructions

1. Insert site title block
2. Set some custom margin sizes in theme.json for core/site-title
3. You should see the margins correctly applied in the editor, but they are not applied correctly on the front end

Example theme.json:

"core/site-title": {
				"spacing": {
					"margin": {
						"bottom": "32px",
						"top": "32px",
						"left": "0",
						"right": "0"
					}
				},

Screenshots, screen recording, code snippet

No response

Environment info

No response

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[tellthemachines]

This one hasn't been fixed by #47858 because that PR only changed the specificity of the flow/constrained layout styles, but this issue is about flex.

The margin reset was added to flex layouts because it was thought that within a flex context the gap value should prevail over any global margin specific blocks might have. As with any blanket rule, there are probably cases where we don't want this to happen, but would we want to remove that rule altogether? Or would we want to reset only left/right margins in horizontal flex layouts, and top/bottom margins in vertical ones? (What should happen if they wrap though?)

At the very least, the discrepancy between editor and front end is worth addressing, but it would be good to be sure of the best approach beforehand.

[andrewserong]

Very good point about whether or not the flex margin rule should stick and allow gap to override any block's margin rules. I have an experimental PR open in #50825 to potentially look at reducing the specificity of that margin rule for consistency with flow/constrained. I'm happy to close it out, though, if the consensus is that flex should have the higher specificity. There's some helpful feedback on that PR, too, about dealing with classic themes' editor styling if we do want to go down the route of reducing specificity.