Try: Make empty paragraphs take up the same space on the frontend, as in the editor #27995
Conversation
|
Size Change: +108 B (0%) Total Size: 1.28 MB
ℹ️ View Unchanged
|
|
Thanks for taking on this long-standing issue!
While this definitely does remove visual clutter, I am concerned that at a glance it implies that there's space there — without a placeholder, all those empty paragraphs look just like a deselected spacer block. But they won't render that way on the front end (Related: #10051).
It's a little unfortunate, but yeah I think an attribute is the best technical solution. |
|
Thank you Kjell, and happy new year by the way!
Delicious point. That seems like a problem to solve, honestly! I took a stab and even included your
Frontend:
This is the code that does it: Basically that outputs a non-breaking space in an empty paragraph, making the empty paragraph technically not be empty, but having the exact same height as if it had text content. Behold:
Fixes #10051 This obviously needs a total sanity check by you and others. CC: @jffng @scruffian @MaggieCabrera and anyone else who might have an opinion, because it basically adds an unscoped rule to the empty paragraph. But the question is: should you ever have an empty paragraph that wasn't the height of a non-empty single line paragraph? |
|
I like that. 😄 But I also wonder if rolling it out at this stage will cause a bunch of headaches for existing sites? |
|
I think rolling out the height of an empty paragraph would require updating themes, so it would only be available in themes that support it. But also it is counter to how HTML defaults work, an empty paragraph tag has no height by default, Altering this might have unintended consequences with people's content. A question I have for this ticket, is it to reduce noise in the editor? Or provide a way for a user to create space around content? Both? Would a dismissable tooltip work? Something that introduces them to the Spacer block, maybe triggered after 3 new empty paragraph tags? |
We ran a quick anonymous data sampling on WordPress.com websites, and found that about 1.6% of published posts/pages contained
It's to further the consistency and WYSIWYG between the editor and the frontend. If you make and see a linebreak in the editor, that linebreak should also be present on the frontend. From #10051, this is the current behavior:
I'd think the most important aspect of this PR, is to make left and right look mostly the same. |
|
My Opinion, some of this has already been touched on in previous comments. Because the empty paragraphs are collapsed on the front end, it's likely that most of those empty paragraph blocks are there by mistake from hitting enter or clicking into the insertion point and then not adding anything. I have done it a million times, and it's a pet peeve of mine. The problem I think would be better to solve here is to make it less likely that empty blocks will be created. Adding space to paragraphs added by accident will create more problems than it will solve. Also, I definitely wouldn't want to encourage content creators to use empty paragraph blocks as spacers. |
|
@sirreal I know in the past you have been very observant on side effects from pull requests like this one. If you have time (thank you, and not urgent), and given the context in #27995 (comment), I would very much value your thoughts as well. |
jasmussen
force-pushed
the
try/clean-empty-paragraphs
branch
from
b8dd49e
to
c9ecd69
Compare
|
I have refocused this PR to be only about fixing #10051. The other experiment can be revisited, but did not set hearts on fire and also needed extra work. |
jasmussen
changed the title
|
I have updated the PR to reflect the focus on just the frontend backend consistency. Would appreciate thoughts. As a reminder, we got some numbers in this comment on how many posts or pages might have empty paragraphs. |
|
Thank you for the review, Ari! The potential downside is that people might have accidentally created a bunch of empty paragraphs without knowing it. For It's easy to do in blocks that feature nesting, for example. And when we then roll this out, suddenly those empty paragraphs would take up space. I happen to agree this is worth doing, but I'll leave it up unmerged to gather some additional opinions. |
Yeah, I agree... But that would actually be a "bug" in their content. This PR will make it more apparent and they can then fix their content - something they could not do before this PR since they didn't even know it was an issue. |
|
I think user's expectations when working with an editor like Gutenberg are probably heavily influenced by their experience of other text editors and word processors. In these system it is very expected that an empty paragraph should take up space, and removing that probably is a source of frustration to many users. I agree that we would rather users were inserting spacer blocks rather than empty paragraphs, but I don't think that collapsing paragraph blocks is the way to do that, as it simply causes confusion - why do things look one way in the editor and another way in the front end. All of which is to say I support this change! I also share the concern that this might cause layouts to break from people accidentally inserting empty paragraphs, but it is very hard to know the extent of the problem. My feeling is that its worth trying to make this change and if we get a lot of feedback from people using trunk that it's a problem then we revert before we get to the next release. |
There was a problem hiding this comment.
@sirreal I know in the past you have been very observant on side effects from pull requests like this one. If you have time (thank you, and not urgent), and given the context in #27995 (comment), I would very much value your thoughts as well.
Thanks! I've been sensitive to structural changes to the HTML, but this solution doesn't include any which is quite nice!
This will visibly change site content on the frontend, where collapsed space is now expanded. Is that correct? That can be disruptive for users, but it should be more intuitive for content to match between the editor and the frontend. Let's make sure to call out the possible visual/layout changes in release notes.
|
|
||
| // Prevent an empty P tag from collapsing, so it matches the backend. | ||
| p:empty::before { | ||
| content: "\a0"; |
There was a problem hiding this comment.
This is NO-BREAK SPACE, the same as the pretty common in HTML. I'm not sure how screen readers handle this or whether there are considerations in the accessibility space to take into account.
There are some other characters that we could consider to ensure the p elements don't collapse, ZERO WIDTH SPACE \200B seems like a viable alternative. The advantage is that it's… zero width. It doesn't take up space.
zero-width.mov
There was a problem hiding this comment.
Naturally I got that wrong in the demo. The zero width space is aboove and the no-break space is below in the example. Zero width is the one that has… 0 width 🤦
youknowriad
added
the
Needs Dev Note
|
I wonder if it's time to remove the placeholders from empty paragraphs 🤷♂️ |
|
Awesome, thank you all for the sanity checks. Some legitimate concerns have been voiced. I will be sure to write a dev note, call it out in the theme update notes, and follow up with any PRs necessary. That's the good thing, this is a very very small change, and it's trivial to revert if unforeseen problems arise from this, and if that happens, at least we'll have tried it. I will also follow up with a PR to address this good point. |
This PR actually started out as an effort to do just that, but the code I wrote for it was a little ugly, and I pared it back to focus things up: b8bd5b1 Here's how that looked:
I'm happy to revisit, notably #13599 and #17366 are still open, and could benefit from some thinking here. But this felt like a good start. |
|
Suggested dev note:
|
This one revisits work from #27995 (comment).
|
Hey I am reading through this PR and I am not fully certain of what will happen, and how it works when I test the next version of the Gutenberg plugin. I am very hesitant.
NB! Bottom line is. I believe we just need to test it out and see how it works. |
The answer is in the 2nd part of that sentence... Sometimes people add empty lines in order to add some breathing room to their sentences. The problem whith that however is that there was an inconsistency between the editor and the frontend. This PR just makes the frontend look as the editor does, so any whitespace added on the editor side will now be visible on the frontend.
True, but people used to working with any text editor just instinctively double-hit enter when they want/need some extra space.
Agreed. However, adding paddings/margins etc takes a lot more time... You need to stop typing, get the mouse, go to a block's settings, and edit the paddings/margins etc. Double-tapping the enter key is something that comes naturally to a lot of people so we should take that into account (which is what this PR does) 👍 |
This one revisits work from #27995 (comment).
This one revisits work from #27995 (comment).
* Try: Hide tip from multiple paragraphs, version 1. This one revisits work from #27995 (comment). * Remove hover.
|
@jasmussen My opinion is that the browser has always condensed white space, and this CSS change makes that inconsistent. I think it should be removed. The Trac ticket is https://core.trac.wordpress.org/ticket/52764 |
|
Thanks for the ping. It's sad that shortcodes end up causing this editor/frontend de-sync, so I'll ping a few people for thoughts, and in the meantime I'll prepare a revert PR. CC: @kjellr @scruffian @MaggieCabrera @aristath @jameskoster |
|
As a possible alternate option, would allowing empty Paragraphs to be transformed into Vertical Spacers work? If spacers defaulted to 1em then can be overridden? |
youknowriad
removed
the
Needs Dev Note
Fixes #10051.
If you press Enter a bunch of times, you get this:
Those are empty paragraphs, and seem to suggest you'd get some space there when you publish. But you don't, those paragraphs collapse to nothing, but are still present in the markup. Essentially tagsoup. This PR fixes that.
Before:
After:
Note, an ealier version of this PR also tweaked the behavior of paragraphs in the editor. I have removed that to focus on the frontend backend consistency.