Fix: restore editor canvas padding in classic themes

[Shekhar0109]

What?

Closes #76863

This PR restores the expected 8px padding around the editor canvas when using classic themes. In WordPress 7.0 / Gutenberg, the padding defined in html :where(.editor-styles-wrapper) can be overridden by body { padding: 0 } introduced by global styles. As a result, the editor content touches the canvas edges.

Why?

Classic themes expect the editor canvas to have a default 8px padding. When this padding is overridden, the text appears flush with the edges of the editor iframe, which negatively affects the editing experience and makes the editor visually inconsistent with previous versions.

How?

This change moves the padding declaration from html :where(.editor-styles-wrapper) to .editor-styles-wrapper. Applying the padding directly to .editor-styles-wrapper ensures it cannot be unintentionally overridden by global styles affecting the body. The existing full-width block margin compensation logic remains unchanged.

Testing Instructions

1. Activate a classic theme (for example, Twenty Twenty).
2. Open the WordPress post editor.
3. Narrow the browser width or switch to tablet view.
4. Insert a paragraph or heading block.

Expected result: The editor canvas should display 8px padding around the content instead of the text touching the edges.

Testing Instructions for Keyboard

1. Open the editor using the keyboard.
2. Insert blocks and navigate between them using Tab and arrow keys.
3. Verify the editor layout and spacing remain correct and no visual regressions occur.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: Shekhar0109 <shekh0109@git.wordpress.org>
Co-authored-by: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: andrewserong <andrewserong@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[t-hamano]

Thanks for the PR! It works well in all cases for my test. I tested this PR using Twenty Twenty.

Default

classic.css is enqueued, and a default 8px padding overrides zero padding derived from default theme.json

Add theme.json to theme

Add the following theme.json to the theme:

{
	"version": 3,
	"styles": {
		"spacing": {
			"padding": { "top": "1em", "right": "1em", "bottom": "1em", "left": "1em" }
		}
	}
}

classic.css is NOT enqueued, and the padding defined in theme.json is applied correctly.

Ultimately, this pull request simply increases the CSS specificity of the selector to which padding is applied from 0-0-1 to 0-1-0.

I believe this approach will have no negative consequences, but since we are in the RC phase, let me double-check it. cc @WordPress/gutenberg-core

[Shekhar0109]

@t-hamano Thanks for reviewing and testing the PR. I appreciate the feedback and confirmation that the fix works well. Please let me know if any further changes are needed.

[t-hamano]

If this PR does not cause any regressions, I would like to merge it next week and backport it to 7.0. The missing default padding affects many classic themes.

[andrewserong]

I like this idea. I did a quick search of themes in the theme directory via https://veloria.dev/ (searching on .editor-styles-wrapper) and most themes appear to be overriding other rules than padding, e.g. background color, font size, etc, rather than padding directly.

If themes are overriding padding then the specificity here still seems reasonable as a theme's styles should load in the correct order.

Most importantly, though, since classic themes don't render the overall template that post content lives within, ensuring the minimal padding here is high enough specificity to be applied, seems a reasonable approach to me. Also, full-width blocks still go edge-to-edge as expected:

So, LGTM 👍

I tested across a random assortment of a half-dozen classic themes with > 50k installs on the theme directory and didn't run into any issues.

[t-hamano]

@andrewserong Thanks for the additional review!

[github-actions]

I just cherry-picked this PR to the wp/7.0 branch to get it included in the next release: 81b5dc5