I'll be working on fixing tests and all.

A more conservative approach might be to disable block support for className and dynamically add CSS classes, as was previously proposed in this PR. The advantage of this approach is that it doesn't pollute the saved HTML, so if the impact proves to be significant, we'd be able to revert before shipping the feature in core.

This PR will definitely create back-compat issues for some themes, but I think we should implement it. It fixes a larger problem of styles unintentionally bleeding out elsewhere.

But we do need a followup PR that provides an upgrade path for themers who were using core/paragraph to style general paragraphs, which I think should be styles.elements.paragraph. If we land this early for 6.9, it gives us plenty of time to get the word out and for folks to test.

A more conservative approach might be to disable block support for className and dynamically add CSS classes, as was previously proposed in this PR. The advantage of this approach is that it doesn't pollute the saved HTML, so if the impact proves to be significant, we'd be able to revert before shipping the feature in core.

Personally I would vote for this approach. Adding the class via the render_callback dynamically gives us most of the benefit with almost none of the uncertainty / downsides.

We can then introduce the new paragraph element in theme.json independently from this class name change and treat them as individual features. And we don't have backwards compatibility issues.

Thank you everyone for your opinions. I think the following approach is the best, but is my understanding correct?

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.
2. Adds support for styles.elements.paragraph so that theme developers can still apply styles to all p elements.
3. If any significant issues are discovered during testing, revert these changes before shipping them in WP 6.9 and consider a more optimal approach.
4. Enables the className support for the Paragraph block. This means that when content is updated or a new Paragraph block is inserted, the HTML will have the .wp-block-paragraph class.

Pinging @WordPress/gutenberg-core for visibility

2. Adds support for styles.elements.typography so that theme developers can still apply styles to all p elements.

There is one concern about this: in the default themes, the elements.link field is defined to use styling for link elements in most cases. Example:

{
	"version": 3,
	"styles": {
		"blocks": {
			"core/paragraph": {
				"elements": {
					"link": {
						"color": {
							"text": "#ff0000"
						}
					}
				}
			}
		}
	}
}

Even if styles.elements.paragraph were supported, nested element selectors would not be supported, so we would not be able to write it like this:

{
	"version": 3,
	"styles": {
		"elements": {
			"paragraph": {
				"elements": {
					"link": {
						"color": {
							"text": "#ff0000"
						}
					}
				}
			}
		}
	}
}

Therefore, theme developers are forced to write the following to preserve their existing selectors by using the css field:

{
	"version": 3,
	"styles": {
		"elements": {
			"paragraph": {
				"css": "& a {color:#ff0000;}"
			}
		}
	}
}

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.

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

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.

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

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.

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?

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.

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 :)

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

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?

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.

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.

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.

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?

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.