Twenty Nineteen: Fix editor style compatibility with Gutenberg 7.7 and above

[kjellr]

Recent Gutenberg plugin releases have introduced some block markup simplification, and Twenty Nineteen needs to catch up a little bit to retain parity between the front & back end appearance. A few things that are broken right now:

• Wide alignments sometimes appear only as wide as the text column.
• Full and wide appear centered on the text column
• Full-width blocks sometimes do not take up the full width of the page, and other times they cause a horizontal scroll.
• Wide and full group block children take up the full width of the block by default.

This should be fixed before 5.5, when the changes from the Gutenberg plugin make their way into core again.

Screenshots:

---

The good news is that much of this can be fixed by mirroring the front-end styles on the back end. I'm attaching a draft patch here. It needs a lot of testing with various block scenarios (I know there's a bug with standard and wide block appearing to be the same width inside of full-width group blocks for example). So it needs a few iterations before it'll be ready to go. Here's the current state with the patch applied:

---

cc @joen for some eyes on this in case you have some time.

[Joen]

float broken

[Joen]

float "fixed"

[Joen]

Really nice work, Kjell! This makes it vastly improved, and my go-to theme will become my go-to theme again! Wohoo!

The good things:

• Fullwide works
• Wide works
• The slightly-offset-to-the-left works

The floats aren't working well, though, and I think it's a regression of a previous fix that brought us this rule:

.editor-styles-wrapper .wp-block .wp-block {
    width: 100%;
}

Those rules for whatever reason are applied to floated blocks, meaning they always look non-floated:

https://core.trac.wordpress.org/attachment/ticket/49843/Screenshot%202020-04-08%20at%2008.29.00.png

If I apply width: auto to the float wp-block class, then it looks correct:

https://core.trac.wordpress.org/attachment/ticket/49843/Screenshot%202020-04-08%20at%2008.28.49.png

But I wonder, is there a different way to fix this? I believe the reason for the original rule was that top-level blocks have this calc-based width, but child blocks should not have that. So I can think of two other ways to go about this:

1.

.editor-styles-wrapper .wp-block .wp-block {
    width: initial;
}

I can't recall the IE rules here, but maybe this would work?

.is-root-container > .wp-block .wp-block {
    width: 100%;
}

the 2nd seems perfect, as that root container class is new in the plugin. But it won't work in older versions. We would also need to test the 2nd rule carefully with reusable blocks, as I believe they also add the "is-root-container", even though probably they shouldn't.

Thanks Kjell!

[kjellr]

The floats aren't working well, though, and I think it's a regression of a previous fix that brought us this rule:

Good catch. I think the initial approach is probably the simplest, and I don't think it'll cause any issues. I'd rather avoid targeting .is-root-container, just because I think targeting editor-specific classes has made this file a lot more prone to breaking than it should be.

I've attached another patch. This one fixes that issue, but it does not push the right-aligned items far off to the right of the text column. I think that's fine for now, and it can be fixed in a followup PR. For some reason, I also had to add left and right margins (I think the theme previously relied on those to be provided by Gutenberg, but maybe they are not now?). In any case, here's how that looks now:

This patch also fixes wide alignments inside of full-width group blocks. We should test (both in the current and plugin versions of Gutenberg) with a variety of different layouts to verify that this works well now.

[Joen]

You're the best, Kjell.

Everything is working well now, with and without the plugin. Ship it!

[kjellr]

Just noting that I've tested this alongside Gutenberg 8.2, and it's not working anymore. So it'll need some more work before it lands.

[kjellr]

@Joen when you have a moment, check out 49843.3.patch​. I think the last patch broke due to a couple things:

• The editor now has different left/right margin measurements.
• The DOM structure for wide/full blocks in the editor has also changed.

I'm not 100% sure those new .alignfull/.alignwide classes are necessary... I thought there was an effort to switch to those classnames in the editor, but it looks like most blocks in the editor currently have a .wp-block[data-align="wide"] wrapper, and do not have the alignfull or alignwide classname.

In any case, this seems to work for me, but it could definitely use more testing!

[Joen]

Wonderful patch. It's 95% there. Here are two before pictures:

​https://cloudup.com/cMXJaFX1UFj

Here are some after pictures, showing vast improvements:

​https://cloudup.com/cVYqgxJfKAw

There's one small issue that exists between the 600 and 782 breakpoint with full-wide images:

​https://cloudup.com/c4IQryRQWkc

It's this rule:

@media only screen and (min-width: 600px) {
	.editor-styles-wrapper .wp-block[data-align="full"], .editor-styles-wrapper .wp-block.alignfull {
	    width: calc( 125% + 20px);
	    max-width: calc( 125% + 20px);
	    position: relative;
	    left: -12.5%;
	}
}

If you change that to min-width: 782px (I think that's "break-medium"), everything looks good on my end.

[kjellr]

Thanks for testing! I fixed that issue. I also noticed that the left/right/center alignments that I fixed in this patch were broken again, so I've fixed those. 👍

I'm still seeing a slight horizontal scroll on small screens sometimes, but I haven't been able to pin down the cause. Would you mind taking a look?

[Joen]

I gave this a solid spin, testing normal, wide, fullwide, floated left right, with and without captions, with and without being resized.

I saw no horizontal scrollbars in my case, and everything looked good to me. I don't know what might have caused issues, but this feels solid, and if we discover a reproducible case, seems fine to follow up. 👍 👍

[poena]

Right aligned text inside groups does not align

[kjellr]

To aid testing, here's some sample post content:

• Group Block with various alignment options: ​https://cloudup.com/i6lmPQrsIsQ
• Image Block with standard/wide/full alignments: ​https://cloudup.com/iGEsOY_O1Kh
• Image Block with left/right/center alignments: ​https://cloudup.com/izdqz8YVgXt

[poena]

Left position of inner content in full width group

[poena]

Left position of inner content in wide group

[poena]

The left spacing for the inner content of the full width group block is not the same in the editor and the front, and does not match the wide group block.

The image of the wide group block is only added for comparison.

I will leave it up to you to decide how much is overkill.

---

Chrome 83.0.4103.116:

I do not see the horizontal scroll in the editor in the image tests.

I do see a horizontal scroll in the editor at 767px when the standard and wide group block widths are stretched to the same width.

Maybe caused by:

.editor-styles-wrapper .wp-block {
    max-width: 100%;
}

---

Firefox 78.0.1:
I do see the horizontal scroll in the editor in the image tests at 767px.

[kjellr]

Thank you for reviewing, @poena! 🙌

Right aligned text inside groups does not align

Since this only effects the front end, I think we can handle it separately. So far, this PR only touches editor styles.

The left spacing for the inner content of the full width group block is not the same in the editor and the front, and does not match the wide group block.

Good catch! Some of the full-width Group block styles were not being correctly picked up there. Should be fixed as of 49843.5.patch​:

Chrome 83.0.4103.116:
I do not see the horizontal scroll in the editor in the image tests.

I do see a horizontal scroll in the editor at 767px when the standard and wide group block widths are stretched to the same width.

Firefox 78.0.1:
I do see the horizontal scroll in the editor in the image tests at 767px.

I see that too — I can reproduce by making a full-width Group block and then putting anything else inside it. But the weird thing is that in some cases, the scrollbars disappear when I select the block. 🙃

I haven't yet been able to pin down the cause, but I'm wondering if it makes sense to push this for now and tackle that separately. I'd rather not hold up all these changes just because of that.

Does that seem reasonable to you folks too?

[poena]

Replying to kjellr:

Does that seem reasonable to you folks too?

Yes

[kjellr]

@ianbelanger any chance you can take a look at this one? I think it's ready to land, and it would be great to get it in soon so things don't appear broken once 5.5 lands.

Thank you!

[whyisjake]

In 48602:

Bundled Theme: Ensure parity between the block editor and the front-end in twentynineteen.

Alignments and blocks were not always appearing as they should in the admin.

• Wide alignments sometimes appear only as wide as the text column.
• Full and wide appear centered on the text column
• Full-width blocks sometimes do not take up the full width of the page, and other times they cause a horizontal scroll.
• Wide and full group block children take up the full width of the block by default.

Fixes #49843.
Props kjellr, Joen, poena.

[whyisjake]

Will want to make sure that these changes are made into the 2019 (non-core) theme too.