Why there is a <br> in the ProseMirror view by default?

[caocanx]

<div contenteditable="true" translate="no" class="ProseMirror">
    <br class="ProseMirror-trailingBreak">
</div>

[smoores-dev]

This is the default ProseMirror behavior: https://discuss.prosemirror.net/t/new-nodes-without-br/865/2

Those are there because, due to historic accident, browsers expect them to be there in empty editable elements, or they won’t show the element at all. They are not part of your actual document, so you don’t need to worry about them.

[caocanx]

This is the default ProseMirror behavior: https://discuss.prosemirror.net/t/new-nodes-without-br/865/2

Those are there because, due to historic accident, browsers expect them to be there in empty editable elements, or they won’t show the element at all. They are not part of your actual document, so you don’t need to worry about them.

Thanks for your reply. But I still have a question, today we can return a <div contentEditable></div> in react and the browser can just render it without a <br> inside. And I saw that discussion in the link is about 7 years ago, so I think is there a way to fix it now?

[caocanx]

This is the default ProseMirror behavior: https://discuss.prosemirror.net/t/new-nodes-without-br/865/2

Those are there because, due to historic accident, browsers expect them to be there in empty editable elements, or they won’t show the element at all. They are not part of your actual document, so you don’t need to worry about them.

Thanks for your reply. But I still have a question, today we can return a <div contentEditable></div> in react and the browser can just render it without a <br> inside. And I saw that discussion in the link is about 7 years ago, so I think is there a way to fix it now?

I find there is still have a <br> inside after click the <div contentEditable></div>, but before click it not have the <br>.

[smoores-dev]

It's a fair question! I think this conversation is probably better suited for the ProseMirror forum; I'm less familiar with the nuances of contentEditable support in browsers, and this library aims to have identical behavior to ProseMirror wherever possible.

[caocanx]

It's a fair question! I think this conversation is probably better suited for the ProseMirror forum; I'm less familiar with the nuances of contentEditable support in browsers, and this library aims to have identical behavior to ProseMirror wherever possible.

You are right, we should discuss there.

[smoores-dev]

@caocanx in case you're still interested, I actually had to add these trailing <br> (and <img>!) hacks in even more places (#122, matching prosemirror-view's behavior) to resolve selection bugs in Chrome, Safari, and Firefox! These are definitely still necessary and relevant to allow users to place cursors within empty text blocks, as well as at the end of text blocks whose last child nodes are atoms or are not contenteditable!

[caocanx]

@smoores-dev thanks for your information. Very useful! 👍