[2.0.3] `getSemanticHTML` is broken
Steps for Reproduction
- Reproduction
- Check the console
Expected behavior:
The text in the editor is a text with multiple spaces. getSemanticHTML returns <p>a text with multiple spaces</p>. Which is wrong - the semantics of the text has changed.
Actual behavior: See above.
Platforms: Any.
Version: 2.0.3
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.
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 ')
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?
I think @luin can help us here
Thanks
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.
We have the same issue please revert this change. Don't want to save nbps to the database.
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.
Could this be a configuration option? So when someone needs it to be "normal" spaces it can?
commenting to follow, hoping to see an update here.
IMHO this is critical bug
Completely destroys displaying edited text for me, since text now fails to wrap. Please revert.
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.
Any update on this @luin?
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?
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!).
@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
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.
Yeah. Not another drama please.
Jeez this thread is a joke. Just do this in your code: input.replace(" ", " ")
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 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.
Probably you are.
Or, @DirkLachowski, since there are so many of us here, our way of using Quill is not wrong either. 🥰
@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.
@islandmyst Your solution works for me. Thank you for posting that! Did you make a pull request for that fix?
@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 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 07b68c98b3bb61e6a6efb369a76f44a16b278517 and allow getSemanticHTML() to output the intended HTML, then we would have the expected results.
@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 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 https://github.com/slab/quill/issues/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.
I opened a pull request with a fix. Hopefully it will get approved.
I opened a pull request with a fix. Hopefully it will get approved.
Thank you @stashaway and I hope it gets approved as well
The PR is this: https://github.com/slab/quill/pull/4587.
I created an alternative fix (PR #4598) that introduce options to getSemanticHTML, so it can be used as it is (with ) for internal coping and pasting in quill. Setting preserveWhitespace option to true will preserve whitespace for all of us needing it.
Any updates?
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...