Empty paragraph block should not be outputted on frontend

[CreativeDive]

Hey,

if a block has a empty paragraph block inside, like the following example:

In this case, the block get an empty paragraph on the frontend view.

However, if there is an empty paragraph, it should not be output.

When will the empty paragraph be added to the block?

If I go down with the keyboard, the empty paragraph is added.

[gziolo]

It’s a common issue for many existing blocks that they don’t take into account a placeholder state. We discussed it with @aduth and @mtias on WordPress Slack last week in a different context. There is a discussion summary posted in #16283 (comment).

[aduth]

It's not clear to me that the solution here is to omit empty paragraphs. A better option may be to improve the usability around if and how new paragraphs are created. I think especially in these nested contexts, it's too easy to accidentally create a paragraph when one isn't desired.

Another (perhaps additional) option may be that we don't consider this as a block until either the user starts writing in it, or they explicitly choose the type of block to be inserted.

[CreativeDive]

Yes, I think it is necessary to improve usability. But as a result, an empty paragraph may not appear in the frontend because it inserts extra spaces that are not desired from the design point of view.

This p:empty {display:none} should not be a solution :-D

[aduth]

On the flip side, it's not clear to me that we can eliminate empty paragraphs from a saved post without also incurring some unintended consequences. There may or may not be a legitimate case for having the empty tag, but even if we were to remove them, at what point would they be removed? While the user is typing? That seems like it could be frustrating usability for the editor. When the post is saved? That seems like it would be unexpected, since from the user's perspective they had expected them to exist in the content and then they've suddenly disappeared.

There is some precedent to this actually. If the post is saved, and the only content is an empty paragraph, we don't save anything. This was implemented for similar reasons, since it's easy to inadvertently create a paragraph when starting a new post, then saving the post while not really intending for it to contain the paragraph.

I think it could do for some additional design feedback, since there's a large element of this that's general usability.

[paaljoachim]

We had an active discussion going forth and back on how to solve this issue.
(Registration to WordPress Slack is needed to view the content of this link.)
https://wordpress.slack.com/archives/C02S78ZAL/p1586278035336100

Some comments made during the discussion:

Agree that it shouldn't render p tags if there’s no paragraph. I believe there’s a similar issue about the Buttons block. #17221

I feel the opposite here.
I think if the user added the empty Paragraph, it should remain.
If the editor is adding it unintentionally, than it should be removed.
That last part gets back to the UX.
There are several scenarios I’ve used an empty Paragraph block to achieve a desired outcome on the frontend. My latest one was using the Columns block as a chart to visualize data.

There’s cases for both, and I know there’s been plenty of times I’ve accidentally added paragraph blocks to try and achieve something
Empty p blocks could be
perhaps, not sure though

empty paragraph vs spacer block

If it's the editor adding it, it should be removed. If it's the user, let them do what they want. (adjusted comment for clarity.)

from W3C:
We discourage authors from using empty P elements. User agents should ignore empty P elements.
https://www.w3.org/TR/REC-html40/struct/text.html#edef-P

My theme had to use some styles for :empty in order to get the blocks styled correctly...

If an empty P is being used as a layout hack, then I’d argue it shouldn’t. The spacer block is for that.

I’d also note that there might be a consideration for “ending” empty paragraphs, vs “middle” empty paragraphs.

Accessibility concerns: Using empty

elements to add space between paragraphs is problematic for people who navigate with screen-reading technology. Screen readers may announce the paragraph’s presence, but not any content contained within it — because there is none. This can confuse and frustrate the person using the screen reader.

And it could be a placeholder for whatever the boss says to put, but they don't have the content yet...

[johnstonphilip]

What about this:

If the block is nothing but an empty paragraph, output nothing. But if there's anything else, like a background color, or any other setting at all saved with the block, keep it as is.

[paaljoachim]

Thinking out loud....

First of all. I really like @johnstonphilip Phils suggestion about "If the block is nothing but an empty paragraph, output nothing."

Let's say that I am a user who just started using Gutenberg. I easily notice that I can click enter a few times and the cursor moves line by line down the page, and think this is a good way to add some space. I check the frontend and depending on theme I believe a visual space is seen or no space is seen. If no space is seen I would think "heck I added space to the backend" why am I not seeing it in the frontend.

What do to when a user clicks enter a few times to add space. One issue addresses this here:
Have multiple empty paragraph breaks -> convert to spacer block
#17366

As the user needs to understand that the correct way to add space is using a spacer block, and we really should help them add the block to create space. But the most natural way is actually to just press enter a few times as if it was a text document. Having a way to automatically create a spacer block as is suggested in the above issue would likely help.

[aristath]

As the user needs to understand that the correct way to add space is using a spacer block, and we really should help them add the block to create space. But the most natural way is actually to just press enter a few times as if it was a text document. Having a way to automatically create a spacer block as is suggested in the above issue would likely help.

That's an interesting idea... A prerequisite to that would be to first change the spacer block to accept any CSS value instead of px-only (slider). That way we'll be able to use in the spacer font-size-relative values which will equal the height of a blank line.

[paaljoachim]

Actually there is an issue for it here:
Spacer Block: Add custom unit support for height control
#22956

[paaljoachim]

@jasmussen Joen has been working on these things.

[jasmussen]

Thank you for the ping, Paal!

@CreativeDive is deleting the empty paragraph not an option for you?

[CreativeDive]

@jasmussen and @paaljoachim

At the meanwhile I have found a good workaround for me to handle this issue:

/* Issue: Empty paragraph blocks adds unnecessary empty spaces to the content */
/* Workaround: Add a visible highlighted border to empty paragraph blocks inside the block editor */
/* So we can see a remove this blocks. */

[data-type="core/paragraph"]:not(.is-selected) span {
	position: relative;
    padding: 4px 6px;
	border: 1px solid #d66f4f;
}

[data-type="core/paragraph"]:not(.is-selected) span:before {
	content: 'Remove or add content';
	display: flex;
    align-items: center;
	position: absolute;
	height: 20px;
	top: -20px;
	left: -1px;
	padding: 0 9px;
	background: #d66f4f;
	color: #fff;
	text-transform: uppercase;
	font-size: 9px;
    white-space: nowrap;
}

[jasmussen]

Interesting solution! Does that solve your issue so we can close this one?

[CreativeDive]

@jasmussen if adding empty paragraphs essential for the block editor, yes please close it. I think my solution is a good solution for anyone who wants to deal with it.

[jasmussen]

I think there's a discussion to be had on what empty paragraphs mean for the writing flow, absolutely. But perhaps we can close this one in favor of #13599 and #17366. I'll do that for now, but happy to undo if this resurfaces.

Thank you!

[CreativeDive]

@johnstonphilip and for whatever reason, if you want to display an empty paragraph block with a background color, you could expand the upper workaround it that way:

[data-type="core/paragraph"]:not(.is-selected):not(.has-background) span {
	...
}

[data-type="core/paragraph"]:not(.is-selected):not(.has-background) span:before {
	...
}