Add CSS class to paragraph block

[juanfra]

Addition by @t-hamano

To resume this PR, I did the following:

• Merge the latest trunk into this branch
• Resolve all conflicts
• Rechecked the whole code and added the missing paragraph block class

This PR has a lot of diffs, mostly related to testing and documentation updates.

The actual files to check are:

• packages/block-library/src/paragraph/block.json: The paragraph block will have the class name wp-block-paragraph added to it, and the CSS selectors generated by the global styles will also use this class.
• packages/block-library/src/paragraph/index.php: Add a class name to the Paragraph block that is already saved in the database via the render callback function.
• The unit tests below also exist in the core, so similar changes will need to be made there as well, probably after this PR is bundled into the core:
  • phpunit/block-supports/layout-test.php
  • phpunit/block-supports/typography-test.php
  • phpunit/class-wp-theme-json-test.php
• The following unit tests do not exist in the core, so they do not need to be backported to the core:
  • phpunit/blocks/render-block-media-text-test.php
  • phpunit/blocks/render-block-paragraph-test.php

---

Original description by @juanfra

What?

Adding the wp-block-paragraph to the paragraph block elements.

Fixes #46863

Why?

It was reported in #46863 that the style changes for the paragraph block were affecting all the paragraphs, and this was affecting other pieces of the site such as the site tagline (and others).

How?

Adding the wp-block-paragraph class to the paragraph block for new content, and parsing the block output to add it for previously generated content.

Testing Instructions

For new content

1. Create a new page with the build from this PR.
2. Add some paragraphs
3. Save the page.
4. Confirm that the paragraphs have the wp-block-paragraph class.

For previously generated content

1. Create a sandbox with the trunk build for this plugin.
2. Create a page with paragraphs (you can use custom classes).
3. Save the page.
4. Update the build to this one.
5. Open the page and confirm that the wp-block-paragraph class was added to the previously generated content.

For the problem reported in #46863

1. Open Site Editor > Styles.
2. Head to Blocks > Paragraph
3. Make changes and notice it doesn't have an impact on the Site Title and Site Tagline (or any other <p> that doesn't have the wp-block-paragraph class)

Screenshots or screencast

Screen.Recording.2023-02-03.at.17.18.43.mov

[juanfra]

I'll be working on fixing tests and all.

[mtias]

I'm not sure we should do this. The original issue describes problems with site tagline and site title, two blocks that are good candidates to be a paragraph block + bindings in the future instead of separate custom blocks, so they would probably inherit the classes anyways.

[carolinan]

I think we must to consider other than core blocks, anything that uses <p> is affected by the current problem.

[t-hamano]

1. Dynamically add a CSS class to the Paragraph block and change the global style selector from p to .wp-block-paragraph. This allows users to test the new behavior on sites that use the latest Gutenberg plugin. However, the className support for the Paragraph block remains disabled, so the HTML saved to the database remains unchanged.

I would like to recommend this approach, but implementing it in this PR would require reverting too many files, so I have submitted a new #71207.

[scruffian]

What is the use case for setting styles on the paragraph block?

[t-hamano]

What is the use case for setting styles on the paragraph block?

For example, a user may want to change the typography styles on the Paragraph block via the global styles. The problem is that this style will affect p elements outside of the Paragraph block as well. Currently, there is no way to apply a style to just the Paragraph block.

The purpose of this PR is similar to #42122.

[scruffian]

For example, a user may want to change the typography styles on the Paragraph block via the global styles.

Why would a user want to do this? What would it achieve?

[t-hamano]

For example, a user may want to change the typography styles on the Paragraph block via the global styles.

Why would a user want to do this? What would it achieve?

I don't think there's any particular reason. I think users simply want to change the style of the paragraph block, just like with any other block.

[scruffian]

I don't think there's any particular reason. I think users simply want to change the style of the paragraph block, just like with any other block.

Without a use case in mind it's hard to be certain that the current behaviour is not the right one :)

[t-hamano]

Users want to apply styles to Paragraph blocks only, without affecting other p elements. Isn't this exactly the use case?

[ramonjd]

Users want to apply styles to Paragraph blocks only, without affecting other p elements. Isn't this exactly the use case?

I think it's conceivable that someone out there might want to:

1. Set a root typography style for the entire site
2. Create an exception for paragraph blocks

Why not?

Edit: I realize this is already possible, but I forgot to mention the assumption that it'd be done to the exclusion of paragraph elements that live in cover blocks for example. In that case, you'd want the cover block global style to have precedence. All that comes to mind is a news site - it's text-based, and article paragraphs have a syntactical relevance that might need to be style to the exclusivity of all others. I'm reaching 😄 Might be an edge case; the original issue outlines another. Can folks think of better examples?

[carolinan]

Users want to apply styles to Paragraph blocks only, without affecting other p elements. Isn't this exactly the use case?

Exactly. And to have different styling for P elements inside other blocks without added complexity.

[scruffian]

article paragraphs have a syntactical relevance that might need to be style to the exclusivity of all others

Thanks for the example @ramonjd. In this case I would expect that styling the Post Content block would be more effective, since paragraph blocks are more general purpose.

[t-hamano]

Please note that there is also a classic theme that has a theme.json. The post content block does not exist in the classic theme.

[carolinan]

I think we are missing the reason why there is a reluctancy to add this. I don't see the motivation voiced here?

A motivation such as "I think it is a bad idea to add a class to the paragraph because it will increase the size of the markup exactly because the paragraph is the most used block".

One person made the argument that the current way the paragraph is styled may be wrong.
I can perhaps buy that we as contributors made a mistake by allowing the paragraph block to be styled with global styles and theme.json in the first place: But I don't see a way to back out of it now since removing this ability would break the styling of existing sites? Do you?

[t-hamano]

I can perhaps buy that we as contributors made a mistake by allowing the paragraph block to be styled with global styles and theme.json in the first place: But I don't see a way to back out of it now since removing this ability would break the styling of existing sites? Do you?

I don't think the fact that global styles and theme.json support the paragraph block is a problem in itself, but I think the important thing is whether we should use an element or class name selector.

Currently, the Paragraph block is the only core block that defines an element as a selector instead of a wrapper classname, which I find strange.

---

P.S. I did a bit of history research and discovered that the wrapper classname for the Paragraph block (formerly known as the Text block) was intentionally disabled from the very beginning when the mechanism was introduced (over 8 years ago!).

https://github.com/WordPress/gutenberg/pull/1381/files#diff-7ae639823f537a52a09815b3df39ae066a9b3b86c95c185abe184d4c246aba45R26

I'm not sure why the wrapper classname was disabled, but maybe there was no global styles or theme.json back then, so there was no need for a classname on paragraph elements.

[t-hamano]

For a more limited approach, I updated #71207. That PR dynamically adds a CSS class to the Paragraph block, but keeps the CSS selector as it was: p.

[juanfra]

Thanks for the update, @t-hamano! I see #71207 takes the render-only approach vs. also including the classname in the editor context (className disabled for block). Makes sense as a more limited scope, we've been working on this angle for a while.

Since #71207 has been merged, I'll go ahead and close this PR. We should also close #46863 since that's addressed now.

[t-hamano]

As a follow-up to #71207, we could revisit the following if necessary:

• Should we statically inject CSS classes into the Paragraph block? This means changing className support to true.
• Should we change the CSS selector for the Paragraph block from p to .wp-block-paragraph to resolve issue Styles: Paragraph styling impacts Site Title & Site Tagline #46863?
• Should we add support for the p element in theme.json?

[aaronrobertshaw]

Should we statically inject CSS classes into the Paragraph block? This means changing className support to true.

I'm not sure on this one. Like with the current approach to adding the class name in a backward compatible manner, would this provide any benefits?

Should we change the CSS selector for the Paragraph block from p to .wp-block-paragraph to resolve issue

I'm generally wary when it comes to increasing any CSS specificity. More detailed discussion might be better on the linked issue.

Should we add support for the p element in theme.json?

If we are looking for generic site wide text styles I think we sort of already have that covered via the text element although that will generate the styles for the body element. I'd be interested if there were any use cases where the lack of a p element for blocks would be a show stopper.

It's also possible that paragraph vs text elements at the global layer would cause confusion.

[t-hamano]

Should we statically inject CSS classes into the Paragraph block? This means changing className support to true.

I'm not sure on this one. Like with the current approach to adding the class name in a backward compatible manner, would this provide any benefits?

There is no particular benefit 😅 I was just wondering if we should inject the class name into the Paragraph block as well as the Heading block:

gutenberg/packages/block-library/src/heading/block.json

Line 31 in c9ca218

"className": true,

I'd be interested if there were any use cases where the lack of a p element for blocks would be a show stopper.

Regarding this, #47282 (comment) by @justintadlock may be helpful.

Block theme authors have been forced for the past several years to use the Paragraph block to style general <p> tags because there is no other way to do so via theme.json.

Personally, I don't think it was a good idea to do this, but that's the system that existed if those authors wanted to avoid writing custom CSS and use theme.json.

With this change, those styles on the Paragraph block that were previously applied to all <p> tags will no longer be applied to <p> tags. Thus, it would break style expectations.

Because of this, there should be an element that can be styled via styles.elements.p (or styles.elements.paragraph) in theme.json. Without this, this PR runs the risk of breaking styles that were applied to all <p> tags before. This would give theme authors an upgrade path.

[aaronrobertshaw]

Regarding this, #47282 (comment) by @justintadlock may be helpful.

This is just my two cents but I think we could start out by not updating the root selector for the paragraph block, leaving it as p. This would keep things mostly as they are now, maintaining backward compatibility. Then for new features like line indent, we define the appropriate selector in block.json for that feature e.g. under selectors.typography.textIndent