Ckeditor5: <br>

[scottfr]

📝 Provide detailed reproduction steps (if any)

Paste <p>a</p><p><br></p><p>b</p> into the editor.

✔️ Expected result

The editor will have:

a

b

This is the CKEditor 4 behavior and the behavior of most other editors.

❌ Actual result

The editor will have (note the two blank lines instead of one):

a


b

---

If you'd like to see this fixed sooner, add 👍 to this post.

[mlewand]

Issue is being caused by the fact that extra filler is added to the paragraph, and this is in fact different from CKE4. Here's how the view is rendered:

<p>a</p>

<p><br><br data-cke-filler="true"></p>

<p>b</p>

[mstermaaten]

Jupp, pretty annoying.... Need this fixed 2
https://github.com/ckeditor/ckeditor5/issues/5589

[Reinmar]

Is this a regression, guys? Did it work well in previous versions of CKEditor 5? It seems suspicious that there are two bug reports about this in a short period of time.

[andreyalikberov]

Pretty annoying indeed. Does anyone know if this can be fixed?

[jodator]

@mlewand & @Reinmar is this a bug or expected conversion an empty paragraph with s soft break inside?

<p>foo<br>bar</p>

will be rendered as:

foo
bar

and for me the <p><br></p> is just a special case of the above (two empty lines in a paragraph)

More importantly the editor.getData() will return "" for empty two-line paragraph and <p>foo<br>bar</p> for the latter case.

[jodator]

ps.: The same will happen if you press shift+enter in empty editor - you will get <p><br></p> in the data. But to display those two lines we must but a block filler in the editing area do only in editing area you will have <p><br><br data-cke-filler="true"></p> so user can put selection in the second line (after a soft-break).

[scottfr]

Lacking a formal specification for rich text content editing on the web, I think the correct approach is to by default follow the behavior of a vanilla contenteditable field.

In Chrome, if you paste the sample html into a vanilla contenteditable you will get a single blank line between the A and B.

If CKEditor 5 (and other editors), doesn't align with the vanilla contenteditable behavior where there isn't a compelling reason to do something different, it creates unnecessary divergence between itself and other Rich Text Editor's on the web [1]. This creates costs for web developers as if every RTE is doing its own thing, it makes it hard for developers to correctly format their text to be pasted across editors.

[1] Most editors will put a single space including CKEditor 4, TinyMCE, Google Docs, Gmail. The only one I've tested which diverges other than CKEditor 5 is Facebook's DraftJS which strips all blank lines on pasting.

[mstermaaten]

Did someone solve this already?

[mlewand]

I gave it a quick check and this behavior was changed in 10.1.0, was good in 10.0.1 - so it can be considered a regression.

I agree that it's a tricky case.

Let's make a clear list of pros and cons of both solutions:

Current solution (displaying <p><br></p> as _two_ paragraphs)

• ➕ allowing to actually remove the <br>,
• ➖ showing a different content from what the user will actually see in output page (and other apps when working with this particular data).

Proposed (displaying <p><br></p> as a _single_ paragraph)

• ➕ same content in editor as in output and other apps,
• ➖ currently user would not be able to remove or tell that there's an extra tailing <br> at the end of the line

From my point of view better interoperability is more desired, so proposed solution seems to add some value here.

[jodator]

• currently user would not be able to remove or tell that there's an extra tailing <br> at the end of the line

What will happen on shift+enter in empty paragraph? Displaying single line is not an option I think. So if pasting this causes problems I'd remove <br> from <p> if we want to fix this.

[andreyalikberov]

does anyone know what the guestimate in getting this issue fixed is?

[mstermaaten]

To prevent the editor for adding extra
tags i actually removed the
manually by data.replace(/<br data-cke-filler="true">/g, "&nbsp;"); before setting the data.
This has solved the annoying adding of extra breaks bug for me.

[Reinmar]

• It's definitely not a good behaviour. I agree with @scottfr that we shouldn't diverge from what would happen in other editors unless we have very good reasons. This behaviour is a bug.
• It changed in 10.1.0 with the introduction of the soft break feature. Simply, before that all <br>s were completely ignored.
• This issue does not affect data created in the editor as the editor will never output <p><br></p>. However, it's annoying because it affects pasting and, potentially, content ported from other editors (especially those which use plain contentEditable).
• A correct solution isn't that trivial because we need to add support for an alternative block filler. Right now, the DOMConverter instance which handles the data pipeline is configured to use  s. <br> is used as a block filler but only in the editing pipeline. We assumed that one DOMConverter needs to handle just one type of block filler. It turns out that one of them will have to handle two types. It will be an "ugly" change.
• Additionally, the actual <br> filler that we use is detected by the data-cke-filler attribute. The <br> we're dealing with in this case will not have it. So, actually, it's also not that filler.
• My plan for now is to patch DOMConverter#isBlockFiller() to handle a special case there that if the domNode passed is a single child of a block element, it's considered a filler (despite DOMConverter#blockFillerMode being set to nbsp. The confusing logic will be enclosed in this method and easy to document.
• However, I do not plan to handle cases like <p> <br> </p>. From what I can see Chrome and Firefox output exactly <p>x</p><p><br></p><p>x</p> when you type x<ENTER><ENTER>x. So, my goal is to handle pasting that to CKEditor 5.

[Reinmar]

PR landed in https://github.com/ckeditor/ckeditor5-engine/pull/1808.