Post Content: Add typography supports

[aaronrobertshaw]

Related:

• Tracking: Addressing Design Tooling Consistency #43241
• Tracking: Typography Design Tools Consistency #43242

What?

Adds typography supports to the Post Content block.

Why?

• Improves consistency of our design tools across blocks.
• Provides high-level typographic styling for post content.

How?

• Opts into all typography supports.
• Makes font size control displayed by default as per majority of blocks currently.

Testing Instructions

1. In the site editor, edit a template with a Post Content block.
2. Navigate to Global Styles > Blocks > Post Content > Typography.
3. Experiment with typography styles and ensure they are applied in the preview.
4. Confirm styles on the frontend.
5. Reset Global Styles to defaults, select the Post Content block within the preview.
6. On the Block tab of the Settings sidebar, test the typography controls for the individual block.
7. Confirm these work on the frontend as well.

Screenshots or screencast

Screen.Recording.2022-08-18.at.10.12.42.am.mp4

[tellthemachines]

This works fine on the front end, but it's not showing the changes in the post editor. Ideally, we'd be able to preview the actual styles when editing a post.

I don't think there's a way for the post editor to know about the settings of the Post Content block, but it would be useful for things like content size too. I guess it's something to look into.

[aaronrobertshaw]

Thanks for taking the time to review this one @tellthemachines 🙇

I don't think there's a way for the post editor to know about the settings of the Post Content block, but it would be useful for things like content size too. I guess it's something to look into.

It's a bit of a tricky one. Within the site editor, you could configure settings on an individual Post Content block for a particular template. That wouldn't apply in all cases, so not sure if that means we can safely ignore that for now.

If the Post Content block is styled via Global Styles and we added the .wp-block-post-content class to the root BlockList, then it gets those global typography styles applied. I have no idea about the consequences of doing that at the moment.

Example diff just to get class applied and see if styles got picked up in the post editor.

diff --git a/packages/edit-post/src/components/visual-editor/index.js b/packages/edit-post/src/components/visual-editor/index.js
index 0d8614946a..b81c56b8f8 100644
--- a/packages/edit-post/src/components/visual-editor/index.js
+++ b/packages/edit-post/src/components/visual-editor/index.js
@@ -265,7 +265,7 @@ export default function VisualEditor( { styles } ) {
 								className={
 									isTemplateMode
 										? 'wp-site-blocks'
-										: 'is-layout-flow' // Ensure root level blocks receive default/flow blockGap styling rules.
+										: 'is-layout-flow wp-block-post-content' // Ensure root level blocks receive default/flow blockGap styling rules.
 								}
 								__experimentalLayout={ layout }
 							/>

[tellthemachines]

Yeah, it doesn't seem to have negative consequences. I wouldn't expect there to be any styles attached to that block from our side at least. Might there be any scenario in which a theme would attach a style to that classname and not expect it to display in the editor?

In any case, that would only solve half the problem because it's just as likely settings would be changed in the actual block as opposed to global styles, and there might be more than one instance of the block with different settings.

I'm not sure what's best here. Perhaps we just add this in for now and then think of a good way for the post editor to reflect styles from the block 🤷

[carolinan]

@WordPress/block-themers Any feedback on the discussions above about styling the post content block?

[MaggieCabrera]

This reminded me of #38862 I don't know if solving the connection between the post content block and what shows in the post editor should be done on this PR or not, but it's definitely something that needs to be considered at some point.

[scruffian]

Perhaps we just add this in for now and then think of a good way for the post editor to reflect styles from the block 🤷

I'm not sure this is a good idea. It will mean that we have discrepancies between the front/back end. I think we need to find a way to render content in the post editor inside a post content block before we can do it.

[carolinan]

An example of where there already is a discrepancy between the front/back end is the link color in Twenty Twenty-Three, where all links in the post content block have a color on the front, that is not visible in the block editor.

[scruffian]

I see that as more reason to fix the existing issues rather than creating more :)

[matiasbenedetto]

I submitted this PR a few months ago aimed to fix the fact that style settings from core/post-content block in theme.json are not applied in the editor. It seems to be working fine with most of the style settings but I tried it in conjunction with these changes, and the editor is still failing to display the right font sizes because the properties and class names around font sizing are missing in the BlockList component.

[aaronrobertshaw]

Thanks everyone for the discussion on this 👍

I've rebased this PR to pick up the latest changes from #42270 which from my testing does allow theme.json and global styles for the Post Content block to take effect within the block editor.

Summary:

• If an individual Post Content block for a single post page is configured with block supports, those styles are not applied within the block editor.
• Theme.json and Global Styles are applied correctly now post #42270 as it applies the .wp-block-post-content classname in the block editor.

Options

1. Abandon adopting block supports for the Post Content block:
   • Pro: Doesn't introduce inconsistency between site editor, block editor, and frontend (albeit for a single template?)
   • Con: Decreases design tool consistency across blocks.
   • Con: Doesn't allow for users to override anything set by a theme author via theme.json
   • Con: Doesn't move toward a solution
2. Merge as is:
   • Pro: Given theme.json will style the block, this allows a user to tweak those values via Global Styles.
   • Pro: Allows for individual Post Content blocks to be styled differently to the main single template if added to non-single-post templates
   • Con: Introduces a potentially limited inconsistency between site editor, block editor and the frontend.
   • Con: Requires further follow-up to address inconsistency which might not land before the initial 6.1 feature freeze.

---

My vote would be for Option 2.

Am I missing anything? What do you all think?

[tellthemachines]

Re-tested the changes and can confirm typography settings in global styles are now reflected in the post editor ✅

I'm inclined to merge this as it adds useful functionality, and the post editor not reflecting the styles added at the block level seems preferable to not being able to change typography settings at all.

We will have to address the issue of reflecting block-specific styles in the post editor at some point, as there are already discrepancies in the layout support, but it's highly unlikely that we'll get that in before Beta 1.