Global Styles Layout Padding is being expressed as a negative value

[beckej13820]

Description

I found that groups and cover images set to full width were overflowing the page. This was especially apparent when looking in the site editor at the "zoom out" view.

Step-by-step reproduction instructions

Upon further inspection, in the site styles area, in the Layout menu where content widths are defined, it appears that Padding is being applied as a negative value to full width elements.

Steps to reproduce, insert several cover images and full width groups (using a background color will make this bug more apparent)

In the global styles area, change the padding using the left / right padding slider.

Screenshot: Padding is set to "none" no overflow seen:

Screenshot: Padding is set to "regular" contents are overflowing the page:

Screenshots, screen recording, code snippet

No response

Environment info

I found this issue while working with a WordPress site running WordPress 6.7.1 with the Twenty Twenty-Five theme.

Gutenberg plugin not activated, using default WordPress 6.7.1 version.

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

Please confirm which theme type you used for testing.

• Block
• Classic
• Hybrid (e.g. classic with theme.json)
• Not sure

[bph]

@beckej13820 Thanks for reporting this. Could you also reproduce the same behavior with the Twenty-Twenty-Five theme?

[beckej13820]

@bph Yes, the screenshots and behavior is with the twenty twenty five theme.

[bph]

Hmm, I don't seem to be able to reproduce this with an fresh install of Twenty-Twenty-Five.
I added a cover, a pattern, an image, and a gallery block and set the padding to regular where possible, set the layout according to your screenshots and the Block gap setting.
Is there something else that needs to be changed? Any changes in Theme json or block styles?

[creador-dev]

I also couldn't able to reproduce this issue. Can you give more specific steps ?

[beckej13820]

I tried to create a 7 minute video where I demonstrate the bug and also go through some of the logical places to check. I haven't done anything very custom to these theme, and although this has a theme.json, I have not modified it from what was provided with twenty twenty-five.

https://www.youtube.com/watch?v=GrdW_LOTCFo

[t-hamano]

@beckej13820

Could you upload a zip of your exported theme files here?

Maybe someone else can use that to replicate the issue.

[carolinan]

Twenty Twenty-Five does not include a frontpage template. Which pattern did you select as the base of the frontpage? These page patterns have different markup and to troubleshoot it, like t-hamano suggested, we need to know what that markup is.

[beckej13820]

Thanks for being a little bit patient with me.

Attached is my version of twenty twenty five that includes a front page template. As @carolinan noted, I created that front page template.
twentytwentyfive (1).zip

I was able to go to a fresh wordpress install on WordPress playground, upload this (very lightly) modified theme, and see the same behavior on my local site. I have only done edits in the full site editor GUI, I haven't modified the theme at the theme.json level, or written any custom CSS.

If I abandon any of my customizations, and select one of the prebuilt styles in twenty twenty five, I can still replicate this, which makes me think this behavior has something to do with the way groups, covers, and column blocks are stacked together.

I'm hoping that someone is will be willing to do the replicate on WordPress playground and use their expert eye to try to find the problem.

[creador-dev]

@beckej13820 It looks fine on my end. Please refer to the video below for clarification.

Screen.Recording.2024-12-03.at.7.55.31.PM.mp4

[beckej13820]

Hi @creador-dev ,

Can you try again, but this time use Global Styles > Layout

[creador-dev]

@beckej13820 Thanks I was able to reproduce this bug in your theme only. If you replace theme.json file in your theme with the original twentytwentyfive it will be fixed.

[creador-dev]

@beckej13820 Please replace the theme JSON file with the original version, then verify and confirm if the issue persists.

[beckej13820]

I haven't altered the theme.json file.

But to try to reproduce, I downloaded twenty twenty five from WordPress.org, deleted my existing theme.json from the server, and replaced with a fresh copy.

I'm still seeing the same behavior.

I have also uninstalled twenty twenty five and reinstalled from the GUI, which I believe should have accomplished the same thing.

[carolinan]

Once you save any styles in the Site editor, including the padding you are showing, that is saved to the database.
WordPress will use your custom settings from the database, not the theme.json.
If you deactivate, uninstall, or delete the theme, the data in the database is not reset. The same data will be used again if the theme is activated.

[t-hamano]

I finally figured out what was going on.

Steps

• Enable Twenty Twenty-Five.
• Open any theme template.
• Open Global Styles > Blocks > Group block.
• (Important) Set horizontal padding to 0.
• Insert a Group block into the template.
• Insert a block that supports full width (such as a Heading block)
• Apply full width to that block.
• Open Global Styles > Layout.
• Change horizontal padding.

Video

8a9bdd3b40cf84fbf0f884695c8f0d9f.mp4

Cause of the problem

This should occur in all themes that support settings.useRootPaddingAwareAlignments.

• When the settings.useRootPaddingAwareAlignments is enabled, blocks placed at the root level have the has-global-padding CSS class applied.
• If you apply horizontal padding to your site, the following CSS is applied to blocks with the .has-global-padding CSS class, not to the site root:

  .has-global-padding {
      padding-right: var(--wp--style--root--padding-right);
      padding-left: var(--wp--style--root--padding-left);
  }

• If you insert a full-width block into one of these blocks, the following CSS applies negative margins to the left and right. This is expected to make the block full width:

  .has-global-padding > .alignfull {
      margin-right: calc(var(--wp--style--root--padding-right)* -1);
      margin-left: calc(var(--wp--style--root--padding-left)* -1);
  }

• But if the Group block has zero horizontal padding, this CSS takes precedence:

  :root :where(.wp-block-group) {
      padding-right: 0px;
      padding-left: 0px;
  }
  
  // The following styles are overridden and will not be applied:
  .has-global-padding {
      padding-right: var(--wp--style--root--padding-right);
      padding-left: var(--wp--style--root--padding-left);
  }

• As a result, the full-width block has a negative horizontal margin that causes an overflow.

Solution

I think the only solution is to make the Group block's horizontal padding empty instead of zero.

[t-hamano]

The important thing is that this issue is about CSS specificity, and is not caused by the zoom out mode.

However, I'm not sure if the issue reported here should be considered a bug.

[carolinan]

Yeah there is no "negative padding". It is the margin that uses the padding value for the calculation.

What is the purpose of doing this globally? I would like to understand what the editor (the person, not the Site Editor =D ) was trying to achieve @beckej13820

Open Global Styles > Blocks > Group block.
(Important) Set horizontal padding to 0.

In the zip file, the export of the theme.json expresses this style as

		"core/group": {
			...
			"spacing": {
				"margin": {
					"bottom": "0",
					"top": "0"
				},
				"padding": {
					"bottom": "0",
					"left": "0",
					"right": "0",
					"top": "0"
				}
			},
			...

Which is not part of the theme's original styles.

[carolinan]

It really highlights that the editor needs to show which settings have been changed.
In a scenario where you are:

• Helping a student
• Helping with a support request
• Picking up a project you have not worked on for a time

Not being able to see what site wide changes have been made makes all of this unnecessarily difficult.
Knowing that you can export the settings as a JSON file helps, but you would also need the knowledge to interpret and compare this file.

[ramonjd]

Not being able to see what site wide changes have been made makes all of this unnecessarily difficult.

Good feedback. @annezazu opened this issue a while back now which is related:

• Styles: show a hierarchy of styles clearly (theme, user, global unspecific, global specific, local, etc) #49278

I think the only solution is to make the Group block's horizontal padding empty instead of zero.

Just checking, unset the group block's horizontal padding when settings.useRootPaddingAwareAlignments is true and there's a global padding value? I'm not terribly familiar with the global padding stuff as you can tell 😄 cc @tellthemachines

[beckej13820]

I want to thank everyone who contributed to this thread. Thanks for patience with me, and also being willing to do alot to help reproduce what was actually causing the issue.

The problem was not well described, because I was coming in late to help and support a student, and saw this unexpected behavior, similar to what @carolinan states.

The student who was working on the design is a design student, and has really been struggling with using the site editor. Back when there was a full site editing outreach program, I used to participate in order to share the feedback of novice wordpress users (like this student and sometimes me) because things we got hung up on were often important areas that needed improvement. The problem was probably my fault... I was encouraging her to try to do more changes universally across the entire site instead of tinkering with the settings on each individual block. So she was probably messing with certain sliders just to see what they did. It's a problem with WordPress that no setting / inherited isn't super clearly displayed. It wouldn't surprise me if a student grabs a slider, wiggles it around, says no I don't like that, and puts it back to where it was in the beginning, unaware that putting it back where it first appeared and "reset to empty" are two different things.

I think what everyone said about the need for clearly displayed hierarchy of styles is important, but I also just wanted to ask the question....

Is it expected behavior for full width items to overflow the width of the screen, no matter what the padding settings are on a group? Isn't that a problem as well?

[carolinan]

@ramonjd I think this empty padding is something that the user needs to manage, not the code. Basically they should reset it using the control.
Helping users understand how the root padding works is a big part of the problem.
A user who is working only with the interface will not even be able to tell that this root padding awareness setting is added to theme.json.
A user who is creating a new theme (or site) using a blank theme will not even be able to turn this on or off.

[carolinan]

I know this is going off topic but maybe theme.json settings that can not be changed in the interface should still be visible in the interface?
Maybe there should be a list of items explaining that "Borders are disabled" "Drop caps are disabled" "Root padding something something is enabled"

[tellthemachines]

Is it expected behavior for full width items to overflow the width of the screen, no matter what the padding settings are on a group? Isn't that a problem as well?

Yeah that definitely shouldn't be happening!

Just checking, unset the group block's horizontal padding when settings.useRootPaddingAwareAlignments is true and there's a global padding value? I'm not terribly familiar with the global padding stuff as you can tell 😄 cc @tellthemachines

I'd rather we went the other way around if possible! The root padding logic is non-trivial so I'll have to look into it again, but ideally it would play along with whatever custom padding values are set on the block (whether at a local or global level).

[tellthemachines]

I'm thinking a neat solution to this would be to change the values of --wp--style--root--padding-right and --wp--style--root--padding-left when a block has padding set globally, scoping the new value to the block selector like:

:root :where(.wp-block-group) {
    --wp--style--root--padding-right: 0; // or whatever value has been set for padding-right in global styles
    --wp--style--root--padding-left: 0;
}

I feel like we had this working at some point? Maybe it regressed.

[beckej13820]

@t-hamano Could you suggest a new, more descriptive name for this issue?