Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[2.0.3] getSemanticHTML is broken #4509

Open
boris-petrov opened this issue Dec 1, 2024 · 33 comments
Open

[2.0.3] getSemanticHTML is broken #4509

boris-petrov opened this issue Dec 1, 2024 · 33 comments

Comments

@boris-petrov
Copy link

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
Copy link

Introduced wtih Commit 07b68c9.

The end result of replacing all spaces with &nbsp; (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) => "&nbsp;".repeat(match.length - 1) + " ")
  }

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

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

@frederikhors
Copy link

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

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

@Sergiobop
Copy link

I think @luin can help us here

Thanks

@rubiesonthesky
Copy link

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
Copy link

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

@TheSeg
Copy link

TheSeg commented Dec 20, 2024

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

The problem with all spaces becoming &nbsp; 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
Copy link

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

@Anthonyyp
Copy link

commenting to follow, hoping to see an update here.

@michal-laskowski
Copy link

IMHO this is critical bug

katywings added a commit to lufrai/quill that referenced this issue Jan 3, 2025
@boosh
Copy link

boosh commented Jan 6, 2025

Completely destroys displaying edited text for me, since text now fails to wrap. Please revert.

@Hapanmuffinssi
Copy link

Hapanmuffinssi commented Jan 10, 2025

IMHO this is critical bug

Yes. Very much so. For example, ngx-quill (https://github.com/KillerCodeMonkey/ngx-quill) also suffers from this. If the editor is used as part of Angular reactive forms, the value of the form control has these added characters after user has finished typing something with whitespaces.

@JonasTriki
Copy link

Any update on this @luin?

@KyeRussell
Copy link

The fact that this hasn't been addressed yet has me concerned that I'm not...using Quill correctly, or something. This respectfully seems like an incredibly critical bug. Is there something I'm missing?

@VahidN
Copy link

VahidN commented Jan 24, 2025

Is there something I'm missing?

Yes, it's under the name of Slab now, which means soon or late it will become a commercial product (based on my experience throughout these years!).

@DirkLachowski
Copy link

@VahidN

Yes, it's under the name of Slab now, which means soon or late it will become a commercial product (based on my experience throughout these years!).

Not too sure about this. Biggest pro of Quill is that it's free, not that it's feature complete. If I have to pay for it, there's much better payed alternatives, eg. Freola. I'm rather concerned that Slab is abandoning it. There's 400+ open issues, 60 open PRs and not really much to be seen from the maintainers

@pahen
Copy link

pahen commented Jan 25, 2025

Please, just say you have abonded it @jhchen and @luin so we can move forward and find a solution for the state Quill is in now.

@Sergiobop
Copy link

Please, just say you have abonded it @jhchen and @luin so we can move forward and find a solution for the state Quill is in now.

Don't be dramatic, just stay on version 2.0.2 for now, until they can fix it.

Before version 2, the repository was inactive for over 4 years. It's only been 2-3 months since version 2.0.3

@frederikhors
Copy link

Yeah. Not another drama please.

@boosh
Copy link

boosh commented Jan 26, 2025

Jeez this thread is a joke. Just do this in your code: input.replace("&nbsp;", " ")

@DirkLachowski
Copy link

The fact that this hasn't been addressed yet has me concerned that I'm not...using Quill correctly, or something. This respectfully seems like an incredibly critical bug. Is there something I'm missing?

Probably you are. Most comments complain that this bug has them save &nbsp;s to the DB. If that’s also your problem then yes, you’re using it wrong. You’re supposed to save the delta format, not something rendered. If you need to send html from the ui to your backend, Quill maybe isn’t the right editor for your requirements. If you need html for whatever reason, parse the delta. That’s the usp of Quill, a view agnostic storage format.

@frederikhors
Copy link

frederikhors commented Jan 26, 2025

Probably you are.

Or, @DirkLachowski, since there are so many of us here, our way of using Quill is not wrong either. 🥰

@DirkLachowski
Copy link

@frederikhors

Or, @DirkLachowski, since there are so many of us here, our way of using Quill is not wrong either. 🥰

Well, "correct" is literally there in @KyeRussell 's question, I just reused that wording when answering it. And I beg to disagree, there's an intended way to use Quill.

From the Delta readme:

Deltas can describe any rich text document, includes all text and formatting information, without the ambiguity and complexity of HTML.
(from https://github.com/slab/delta ).

The real problem is that there are not that much Delta to whatever render tools, so people resort to Quill as a Delta renderer. That works sometimes, but it's not a great idea.

@raymondelferink
Copy link

@islandmyst Your solution works for me. Thank you for posting that!
Did you make a pull request for that fix?

@TheSeg
Copy link

TheSeg commented Jan 27, 2025

@frederikhors
Well, "correct" is literally there in @KyeRussell 's question, I just reused that wording when answering it. And I beg to disagree, there's an intended way to use Quill.

If that is the case, then why is getSemanticHTML() a supported function? Emphasis is mine:

Get the HTML representation of the editor contents. This method is useful for exporting the contents of the editor in a format that can be used in other applications.

An end user who presented with wrapping lines in an editor intends to have lines wrap. Swapping for &nbsp; destroys the intentions of the end user's line wrapping. It is simply the incorrect interpretation of the end user's intentions.

If the fix is using the Delta system, then getSemanticHTML() is an unsupported function as it doesn't generate accurate HTML. This would also change the scope of Quill and explicitly only compatible with Delta.

If the fix is to revert 07b68c9 and allow getSemanticHTML() to output the intended HTML, then we would have the expected results.

@DirkLachowski
Copy link

@TheSeg Tell that the maintainers, not me. If you think that that function needs a fix, you can open a PR and we'll see if it will be merged. That said, getSemanticHTML has been added with v2, so we can have a discussion if adding &nbsp; is an error (most likely it is), but it's nowhere defined what the correct output is. Btw, this looks a lot like a private function that just got used a lot by consumers and then got promoted to the public API #3992. So, maybe it's just that the maintainers need it right that way in their products.

That said: Using the Delta format as a representation for content and changes is just a big read flag showing lack of upfront design. So, there's maybe more errors to come and it's time to move on. I'll do so.

@stashaway
Copy link

I opened a pull request with a fix. Hopefully it will get approved.

@trymeouteh
Copy link

I opened a pull request with a fix. Hopefully it will get approved.

Thank you @stashaway and I hope it gets approved as well

@frederikhors
Copy link

The PR is this: #4587.

@MaciejDabek
Copy link

I created an alternative fix (PR #4598) that introduce options to getSemanticHTML, so it can be used as it is (with &nbsp;) for internal coping and pasting in quill. Setting preserveWhitespace option to true will preserve whitespace for all of us needing it.

@helen-andronova
Copy link

Any updates?

@jannes-io
Copy link

Yikes.. breaking backwards compatibility in a patch version... Guess the one take-away we got from this is to fix quill to whatever version works and leave it there until we hit critical vulnerabilities...

jannes-io added a commit to forumify/forumify-platform that referenced this issue Feb 5, 2025
QuillJS 2.0.3 changed the way semanticHTML is rendered by replacing all
spaces with &nbsp;.. what an absolute joke.. slab/quill#4509
@michal-laskowski
Copy link

this must be some psyop. trust no patch.

@raymondelferink
Copy link

I think a patch should be based on the suggested fix proposed by @islandmyst (#4509 (comment))
That means adding multiple spaces in the editor still results in multiple spaces in the rendered html, without the crippling absence of actual spaces.
I'm traveling right now, but if no one has time to make a pull-request, then I will make one after the weekend:-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests