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.

[mdawaffe]

some blocks are changing their width relative to others when zoom out is engaged

That's exactly what I'm seeing :) Though if it's better to consider the border issue as a separate, that's cool by me.

[richtabor]

@stokesman @mdawaffe is this issue still occurring?

[mdawaffe]

@richtabor yes.

[AhmarZaidi]

Hey 👋,
I'd like to work on this issue.

Here are some of my observations:

• The issue occurs with align wide and align full blocks in zoom out mode (align-full cover block example):

  

• The issue doesn’t occur with all the cover blocks (patterns).
  Example: Shrinks when using ‘Centered image with two-tone background color’ block (green & skin color one) but doesn’t shrink when using ‘Heading, Paragraph, Button with Two Images’ (pink one)

• If a pattern that doesn’t have this issue (eg: ‘Heading, Paragraph, Button with Two Images’) is present then other patterns (with the issue) are also fixed (they take expected width). However, I couldn’t find any styling differences b/w those blocks which could cause the issue.

  

---

One solution that seems to fix the issue is to simply remove margin-left: auto; margin-right: auto; from .is-root-container.alignfull from visual-editor style.

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

Line 328 in 650eb7f

.is-root-container.alignfull { max-width: none; margin-left: auto; margin-right: auto;}

Here’s the zoom out view after removing:

• align wide

  

• align full

  

• Also tested Zoom out: wide blocks are shrunken #63519 (comment) and it is also fixed.

  • Before removing auto margins (1st normal, 2nd zoom out)
  
  • After removing auto margins (in zoom out mode)
  

Note: I did remove and test the border rule (#63519 (comment)) but that doesn't seem to fix this issue.

gutenberg/packages/block-editor/src/components/iframe/content.scss

Line 43 in 650eb7f

border: calc(#{$frame-size} / #{$scale}) solid $gray-300;

[draganescu]

Howdy @AhmarZaidi can you open a PR so we can test it out and see what other consequences the edits to the styling of the root container have?

[draganescu]

@ellatrix @stokesman @mdawaffe is this still something you can repro on trunk? I can't 🤷🏻 including with the markup provided.

[stokesman]

Yes, but only in the Post editor on a post (not a page). It seems the theme can make a difference. TT4 is what I was testing with. Adding other blocks/content can make the issue less pronounced or entirely unseen (depending on window width). You can see the issue with the following markup:

<!-- wp:cover {"dimRatio":50,"isUserOverlayColor":true,"isDark":false,"align":"full","className":"is-light"} -->
<div class="wp-block-cover alignfull 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 -->

And add this markup to avoid the issue from being present (unless your window is very wide):

<!-- wp:group {"align":"wide","className":"wporg-gutenberg-block-layout","layout":{"contentSize":"1150px","type":"constrained"}} -->
<div class="wp-block-group alignwide wporg-gutenberg-block-layout"><!-- wp:paragraph {"fontSize":"medium"} -->
<p class="has-medium-font-size">Blocks allow you to build your own custom posts and pages without any coding knowledge. Here’s a selection of the default blocks included with Gutenberg:</p>
<!-- /wp:paragraph --></div>
<!-- /wp:group -->

[mdawaffe]

is this still something you can repro on trunk?

Yes, the issue I have still happens in current trunk. Note that it has a similar symptom as the issue described above by @stokesman but comes from a distinct source. (See #63519 (comment) and earlier.)

1. Activate Twenty Twenty-Four.
2. Create a new post.
3. Add a group block.
4. Set the group block's Alignment to Full Width.
5. Uncheck the group block's "Inner blocks use content width" setting.
6. Add a few paragraphs of lorem ipsum text to the group block.
7. Zoom out and in. Notice that the line breaks in the paragraphs change.
8. Use the browser inspector to find the editor iframe's HTML element.
9. Set that HTML element's border CSS property to 0.
10. Zoom out and in. Notice that the line breaks in the paragraphs no longer change.

If all we were doing was scale()ing, there wouldn't be any layout changes. In addition to adjusting scale(), though, we're changing the border of the HTML element. That change impacts the widths of everything else.

I haven't been following any of the more recent discussion about this (and similar issues). Apologies if there's another thread out there with a better understanding than mine in this one :)

[stokesman]

@mdawaffe, as far as I can tell this issue has nothing to do with the scaling and border. Those are indeed problems and #65814 is aimed specifically at those. I do appreciate your attention to detail and good explanation of what’s going on with the border and scaling 👍.

As best I can see, this issue is due to display: flex being put on the body while zoomed out. #65967 currently resolves this issue though it wasn’t the aim of that PR.

[talldan]

Not sure if it's the same issue, but it seems pretty easy to reproduce this using Twenty Twenty Five, just by adding a single paragraph to a post:

Kapture.2024-10-11.at.16.06.36.mp4

I concur with what @stokesman says, the flex rule is the issue. #66041 is also resolving the issue for me.

[ajlende]

#66041 was merged, and I can't reproduce this issue on trunk anymore, so closing this one.