Zoom out: wide blocks are shrunken

[ellatrix]

Description

Step-by-step reproduction instructions

Open a pattern category from the inserter with the demo content

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

[stokesman]

So far I’ve only reproduced this for cover blocks (wide aligned or not) and it looks like it has to do with the styles introduced in #59512. I say that because in the browser, when disabling display: flex on .is-root-container, I see the width as expected (testing with twenty twenty-four). This probably can affect other blocks or theme styles.

[mdawaffe]

This also affects Jetpack map blocks:

edit mode:

zoomed-out mode:

I don't understand the relevant CSS models well enough to understand the details, but flex changes how widths and heights are calculated, which is going to break different blocks in weird ways.

[mdawaffe]

This also affects Jetpack map blocks

I may have spoken too soon about this, sorry :) The issue with the Jetpack block may be unrelated. I'm still looking into what's happening and will update this ticket when I know more.

[mdawaffe]

My confusion stemmed from a difference between the post and site editors. I'm still not completely sure what's going on, but I think it's the following.

In the zoomed out mode of the post editor, there is no <main> element, so blocks are children of .is-root-container, which has display: flex. Blocks don't expect to be flex elements so can break in odd ways.

In zoomed out mode of the site editor, there is a <main> (display: block) element, so blocks are in their "expected" environment. However, in addition to the transform: scale(), the zoomed out editor's layout changes: the width of blocks change as a result of the border: calc(#{$frame-size} / #{$scale}) solid $gray-300; border rule. The contents of the Jetpack map block are dynamically generated based on the block's width and the block listens for resize events to update itself. When the editor's layout changes because of the border rule, the Jetpack map block doesn't know to recalculate its width and regenerate its displayed content.

Perhaps we can ditch the left/right border rule to prevent the layout change?

[stokesman]

Perhaps we can ditch the left/right border rule to prevent the layout change?

That’s definitely something that should be prevented. The border doesn’t have to be removed though, it’s just not currently factored into the zoom out transform so it throws off the layout.

---

I noticed that with Twenty Twenty-Four and posts (not pages) in the Post editor, the whole of the post content narrows. It’s the auto margins from .alignfull that become filled out with the body being a flex container.

To me it seems any styling changes to the document’s contents in Zoom Out should be avoided as much as possible and we should look for another way to expand the content area that’s more isolated.

[richtabor]

To me it seems any styling changes to the document’s contents in Zoom Out should be avoided as much as possible and we should look for another way to expand the content area that’s more isolated.

Just for clarity, you're suggesting that the border effect is what's causing the problem?

[richtabor]

Also, how do I reproduce this exactly? I'm not seeing the wide cover block on the Gutenberg demo page have this issue:

CleanShot.2024-08-05.at.10.29.41.mp4

[ellatrix]

I'm no longer seeing it. However, the scaling is now broken. Notice how much the wide block overflows with and without zoom-out. Back in May we fixed the scaling so that the width does not shrink.

Wider canvas	Shrunken canvas (should be purely scaled, not shrunken

[stokesman]

Just for clarity, you're suggesting that the border effect is what's causing the problem?

No. The "expand main content area" effect seems to be the cause #63519 (comment).

---

I can still reproduce this with Twenty Twenty-Four in the Post editor on a post—not a page—with the following markup:

<!-- wp:cover {"dimRatio":50,"isUserOverlayColor":true,"isDark":false,"align":"wide","className":"is-light"} -->
<div class="wp-block-cover alignwide is-light"><span aria-hidden="true" class="wp-block-cover__background has-background-dim"></span><div class="wp-block-cover__inner-container"><!-- wp:paragraph {"align":"center","placeholder":"Write title…","textColor":"white","fontSize":"large"} -->
<p class="has-text-align-center has-white-color has-text-color has-large-font-size">Of Mountains &amp; Printing Presses</p>
<!-- /wp:paragraph --></div></div>
<!-- /wp:cover -->

<!-- wp:group {"align":"wide","style":{"color":{"background":"#d9edcb"}},"layout":{"type":"constrained"}} -->
<div class="wp-block-group alignwide has-background" style="background-color:#d9edcb"><!-- wp:paragraph -->
<p>p in widealign group</p>
<!-- /wp:paragraph --></div>
<!-- /wp:group -->

Why this happens on posts and not pages seems to be that the Post content block (.wp-block-post-content) is .alignfull on posts and not pages. Possibly interesting as well is that even if .alignfull is added to a page’s Post content block there is no effect. The particular align styles don’t exist on pages—the styles are these:

gutenberg/packages/editor/src/components/visual-editor/index.js

Lines 325 to 329 in 650eb7f

	// Add some styles for alignwide/alignfull Post Content and its children.
	const alignCSS = `.is-root-container.alignwide { max-width: var(--wp--style--global--wide-size); margin-left: auto; margin-right: auto;}
	.is-root-container.alignwide:where(.is-layout-flow) > :not(.alignleft):not(.alignright) { max-width: var(--wp--style--global--wide-size);}
	.is-root-container.alignfull { max-width: none; margin-left: auto; margin-right: auto;}
	.is-root-container.alignfull:where(.is-layout-flow) > :not(.alignleft):not(.alignright) { max-width: none;}`;

[richtabor]

However, the scaling is now broken. Notice how much the wide block overflows with and without zoom-out.

Yea, you're right.

[mdawaffe]

Just for clarity, you're suggesting that the border effect is what's causing the problem?

There seem to be multiple issues :) I claim that the border rule is one of them.

The computed width (ignoring scale()) of the iframe's body element when using Twenty Twenty-Four:
Edit Mode: 1387px
Zoomed-Out Mode: 1374px <-- Layout change
Zoomed-Out Mode after disabling the html { border: } rule: 1387px

(Note that these widths depend on your browser window's width.)

Edit	Zoomed Out	Zoomed Out with Disabled Border Rule

(You can't see much difference in the thumbnails above, but the computed width for each is visible if you zoom in.)

[stokesman]

There seem to be multiple issues :) I claim that the border rule is one of them.

Yes, the border is part of the scaling issue but not part of what this issue is originally about—that some blocks are changing their width relative to others when zoom out is engaged.