Shift enter at end of text adds data tag to the added <br> tag

[mokimo]

Issue

Undeletable / visible <br> tags at the end of an element.

Description

We're fighting against default browser behavior here as adding a break-tag with shift+enter at the end of a text, will automatically create two break-tags, with one being un-deletable.

Related issue that tinymc has (They have a WYSIWYG-editor): tinymce/tinymce#4856

My suggestion is to just intervene and disallow/remove break-tags at the end of a text. This is more transparent due to the visual feedback, vs hidden <br> tags in the document.

Furthermore, mark all other break-tags (<br data-editable="newline">), because this solution has some tradeoffs as well.

Changelog

• Shift+enter at the end of a line will now add <br data-editable="remove"> instead of <br>
• Shift+enter now marks all the break-tags <br data-editable="newline">

Tradeoffs

• When creating a new line with shift+enter in the middle of a text, then deleting everything after the soft-break, will result in an undeletable break-tag again.
  -> Those would be manually filterable <br data-editable="newline"> scanning for that.

[mokimo]

Let's take it in before the major bump with jquery, hoping looking a bit more into the tests later on

[livingdocs-automation]

🎉 This PR is included in version 1.8.4 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[marcbachmann]

I think I just found the original cause for this issue. It's not the enter which caused issues but the br placeholder we added during a focus event. With the solution in #234 we now have \u0000 as default content, which then results with \u0000 after the content.

focus
type foobar
element.textContent equals 'foobar\u0000'

But as we strip the null escape character away, this doesn't cause any side effect anymore.
This will also be improved in #236

Before the fixes in the other PRs. Right after a focus and typing text. Without ever entering return.