Suggestion: Make empty paragraph blocks behave consistently on the front and backend

[kjellr]

General Idea:

Let's establish consistency around the way that new, empty paragraphs render in Gutenberg and on the front end.

• We could do this by adopting the Classic Editor's method of rendering empty paragraphs as <p>&nbsp;</p> on the front end.
• To complete the effect, we'd likely want to adjust our empty paragraph placeholders so that they only appear on hover and select.

Details:

Currently, Gutenberg and WP-Admin treat empty paragraphs differently:

To me, the classic editor approach is closer to what I’d expect: what I typed in the editor is more or less rendered in the front end.

Here's the technical reason for that difference: Gutenberg renders all those empty blocks as <p></p> and they get collapsed in the front end because they’re empty. By contrast, the classic editor renders all those empty paragraph lines as <p>&nbsp;</p>. Adding   in there may seem a little weird — but for a user who doesn’t care about code, it just ensures that an empty paragraph behaves as expected. This functionality is similar to what you see in any other word processor: you hit return a few times, and you get an extra empty line. I tend to like this approach, and I suggest we consider adopting it.

(Yes, we have a — very useful! — spacer block to add extra space, but that doesn't make a lot of sense if you're in a writing mindset: If you're typing, and you want to add extra empty line, the return is key by far the easiest way to add that.)

---

If we did adopt this, we'd likely want to make a little update to our placeholders too. If empty paragraphs rendered as blank new lines in the front end, they should appear as blank new lines in the backend too.

To accomplish that, one solution would be to switch to showing the placeholder text only on hover and select:

(The "show placeholder until you start typing" behavior is similar to the way slack handles their placeholders.)

This would help us eliminate the very repetitive placeholder effect you currently see when you hit return many times in a row (#2466):

---

We've been having great progress in #9314 around changing that placeholder copy slightly (and also, replacing the default "Write your story" copy at the top of posts with the new version). If the ideas in here make sense for us, I could see this change landing nicely alongside that update.

Looking forward to hearing others' thoughts.

[karmatosed]

I like this, let's get a low priority but 5.0 for this. Would be good to get in but if we don't it could be an iteration.

[sarahmonster]

This seems like a great solution to the problem. Were we to apply this, we'd also want to make this same change for other text-based blocks, like the list, which has slightly more predictable behaviour when rendering "empty" but still doesn't match the unselected state.

Right now, most text blocks work the inverse way of the suggestion here—the placeholder is visible when unselected, and disappears when the block gains focus. It's probably worth testing this change to ensure that switching the behaviour doesn't cause placeholder confusion in users, but it feels like a more intuitive approach to me.

[senadir]

Using paragraphs as a spacing technique could be considered a hack, since the spacer is the most correct use case but not the easiest, we might, might, do a replace on save to change empty paragraphs with spacer block and save it that way

[sabernhardt]

It may be better to disable the automatic creation of another block when the current paragraph block is empty, especially for people who are accustomed to pressing the Enter key twice for a new paragraph.

I tested adding an empty content condition within the "onSplit" rules in the file \node_modules\@wordpress\block-library\src\paragraph\edit.js (see also edit.native.js) :

onSplit={ ( value ) => {
	if ( content == "" ) {
		return;
	}
	if ( ! value ) {

This successfully prevents consecutive empty paragraph blocks, and it still allows intentional use as spacing if a space is typed in that field. (Or users could add content for the next paragraph block and hit the Enter key at the beginning of that.)

However, without adding a function to the code's return; line, this revision does not provide any feedback if you press the Enter key in that block and expect it to do something. Making the standard placeholder text visible again could be sufficient. Otherwise, a special message could show, either replacing the placeholder text or styled like the introductory guide text bubbles, explaining the options to create a spacer block and/or to add a space in the empty paragraph block. (A special screen reader message may be excessive, since tabbing away and back again notifies that the block is empty anyway, and there are other places where pressing the Enter key does nothing.)

[StevenDufresne]

A different way to think/state it would be:

We want it to behave like a text area when we are editing (focused) and to convert the "paragraphs" (sentences separated by empty lines) when we save.