[2.0.3] getSemanticHTML is broken

[boris-petrov]

Steps for Reproduction

1. Reproduction
2. Check the console

Expected behavior:
The text in the editor is a text with multiple spaces. getSemanticHTML returns <p>a&nbsp;text&nbsp;with&nbsp;multiple&nbsp;spaces</p>. Which is wrong - the semantics of the text has changed.

Actual behavior:
See above.

Platforms:
Any.

Version:
2.0.3

[islandmyst]

Introduced wtih Commit 07b68c9.

The end result of replacing all spaces with   (Non Breaking Space) is that the words no-long wrap at word boundaries, and instead overflow.

Example

An alternative implementation of editor.js converHTML() that preserves whitespace might replace all but one consecutive space character with   be:

  if (blot instanceof TextBlot) {
    const escapedText = escapeText(blot.value().slice(index, index + length));
    return escapedText.replaceAll(/  +/g, (match) => " ".repeat(match.length - 1) + " ")
  }

A work around (which replaces the last consecutive   with a space) until a fix is implemented is:

quill.getSemanticHTML().replaceAll(/((?: )*) /g, '$1 ')

[frederikhors]

I think this is bad. Sometimes I need to write   literally in the editor.

Can we revert to the amazing getSemanticHTML() method of the 2.0.2 please?

[Sergiobop]

I think @luin can help us here

Thanks

[rubiesonthesky]

This is quite critical bug to our project. This changes how the values are saved to database. Luckily this didn't hit production before noticing.

[cami-dev]

We have the same issue please revert this change. Don't want to save nbps to the database.

[TheSeg]

Spent the entire day only to discover this is a known and unaddressed bug.

The problem with all spaces becoming   is that it completely breaks pervious word wrapping. It's a non-breaking space, thus all instances that would otherwise line wrap suddenly won't. For a WYSIWYG editor, what you see is currently not what you get.

[EricDitp]

Could this be a configuration option? So when someone needs it to be "normal" spaces it can?