quill: Adding Newline Causes Extra Whitespace Due to
Wrapped in

There is no basis <p>Joe Smith<br />1234 Main St<br />Los Angeles, CA</p> is any better than <p>Joe Smith</p><p>1234 Main St</p><p>Los Angeles, CA</p>. If there is a reason, please supply the source. Otherwise I’m not going to argue about opinions.

You can very clearly type

Joe Smith 1234 Main St Los Angeles, CA

in almost any demo on quilljs.com. This issue is about the particular markup.

Quill requires a block level nodes as children of the root node and all block level nodes to have at least one child. Arbitrary markup is not a project goal so the suggestion would be to control margin with CSS.

hy @jhchen you are right, there is no written basis (or i did not find one so far 😃).

for me a paragraph has always been a container for text which belongs together. that’s for example an address block. or a poem with some lines. or - of course - just some text which you may split (for some formatting reasons or whatever) in some lines but which form one “paragraph” of text.

let’s say i have a text like

Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.

and i want it to look like

Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.

i think it’s not meant to be something like <p>...</p><p>...</p><p>...</p>

or am i wrong?

i think that is what the <br /> is made for. and it’s pity that this is not possible in quilljs. especially because it’s such a great editor so far.

@jhchen i think the markup is just wrong. in quilljs it’s:

<p>Joe Smith</p><p>1234 Main St</p><p>Los Angeles, CA</p>

But it should be <p>Joe Smith<br />1234 Main St<br />Los Angeles, CA</p>

i love quill. but for me it’s also a killer that there’s no support for newline (
). the demo on quilljs.com handles this issue only by formatting a paragraph with no margin. that’s ok for quilljs.com, but it’s simply not right.

Hi!

Just my two cents here: we found this issue here https://github.com/decidim/decidim/issues/2000. Usually, in order to separate paragraphs, most people I know use two newline breaks:

1st paragraph

2n paragraph

This should generate this HTML, IMHO:

<p>1st paragraph</p><p>2n paragraph</p>

A single line break is used for that, as a line break, so this:

A
B

Should generate this HTML:

<p>A<br />B</p>

Is this possible right now?

Thanks!

The missing support for the single line-break is a shame. Quill is a really good project, which I found well documented and mostly easy to use. I just found out about this and will have to switch to a different editor now, just because of this. Kinda angry about it, because I had to google a LOT to finally find out, this is not possible. Please add it to the FAQs.

Coming from a graphic design background, I can ensure you: There is a huge difference between a line-break and a paragraph in typography.

As already stated above: https://en.wikipedia.org/wiki/Line_wrap_and_word_wrap https://en.wikipedia.org/wiki/Paragraph

I really hope, you will add this at some point in the near future.

Until then, all the best.

What would be wrong with using shift-enter to just insert a
instead of adding a new paragraph? This would match what other editors do

This issue with soft breaks doesn’t affect the paragraphs only. This can be solved using CSS. A much bigger issue are breaks inside of list items like these:

• list item 1: some description
• list item 2: some description

This is not possible in Quill. Unfortunately I realised this after I changed the editor to Quill on existing content. Probably I have to stop using Quill because of this.

The missing support for the soft return is really a (big) problem. It’s normal to wrap the text into <p> but it’s impossible to correctly compose a text only with hard breaks, creating a new paragraph everywhere that the line should break. If soft and hard returns have been created, it’s because they are useful. On a Mac, you can compose text using soft returns since 1984, the lack of support for this feature is nonsense. https://en.wikipedia.org/wiki/Line_wrap_and_word_wrap https://en.wikipedia.org/wiki/Paragraph

See the problem is, the <p>&nbsp;</p> approach for new lines works great whenever you have control over the styling of the p tag, but becomes a problem when you don’t.

Example: Using the editor for composing an email, the line spacing looks great inside Quill, but when I send out the html email, every mail client displays unwanted whitespace between paragraphs. Would have been great to have standard markup in this case.

UPDATED Nevermind, changing the default Block tag to div works perfectly for emails. #861

Same here, if you find an alternative please let us know.

I switched to tiptap. https://tiptap.scrumpy.io

i just did like that

<script src="js/jquery-2.2.4.min.js"></script>
<script>
$(function(){
$("br").remove();
});
</script>
</body>

Quill requires a block level nodes as children of the root node and all block level nodes to have at least one child. Arbitrary markup is not a project goal so the suggestion would be to control margin with CSS.

Adding * { margin: 0; } worked for me - you can be as specific or general as you want. This was just my first pass at it.

The problem I see with this is basically about styling - and margins.

What I currently get from quill (react-quill in my case) are <p><br /></p> elements. That’s pretty bad in our case…

In the current project, we use semantic UI. Like most CSS frameworks, it defines some margin-bottom for p elements. This leads to lots of duplicated gaps between lines.

Normally, I’d use something like p:empty {margin-bottom: 0} to cancel that out, but that’s not working here. Having layout issues you can’t solve with CSS is pretty bad…

Is it possible to customize/inject the mechanism for creating linebreaks from the callsite?

Update: Not too bad actually,with the p/br wrap I can just go .content p {margin-bottom: 0;} regardless of empty/non-empty p. Nevermind 😃

There is no basis <p>Joe Smith<br />1234 Main St<br />Los Angeles, CA</p> is any better than <p>Joe Smith</p><p>1234 Main St</p><p>Los Angeles, CA</p>. If there is a reason, please supply the source. Otherwise I’m not going to argue about opinions.

@jhchen I have explained here why the current behavior does not follow the Principle of Least Surprise.

Had to drop Quill as well because of this. While technically we should be using

tags, many people are dealing with content editors that are not tech savvy. Which is why we need to support soft returns creating
tags.

I have tried so many ways how to handle the empty spacing in Quill and now I realized it cannot do even line breaks…

Sure there are tons of reasons why this should be implemented. If not there won’t be two tags <p> a <br> The typography matters that is why we do not use plain text only and look for editors like Quill.

The line break is important and the most essential textual feature in the sentence where there should the line break and anywhere else the writer decides to have it (there are also bad practices indeed ). I do not understand what is so unintelligible about it.

The line breaks work even here on github for reason: Or else this line will be indented by and empty space above which is not desired.

Even more, many languages unlike English have specific rules how the words can be split to a new line, or what kind of word can stay on the end of the line like the sentence cannot end with conjunction for readability purposes and other reasons. Which is unfortunately almost unreal in browsers nowadays… without extra re-formatting of the text before it hits the user eye.

Little bit overwhelming explanation of the line break topic: https://www.w3.org/International/articles/typography/linebreak

This is a really basic function and is integral to the use of editors for many users. Like others, I implemented this fully before realizing this glaring issue. I’m working with existing content from a resource database and have to display it with the existing formatting. And even if I wasn’t, I would not be willing to compromise common usability, because that is the case here. Until this is fixed I will, unfortunately, have to go hunting an alternative solution as well.

This was probably the first thing I noticed when swapping over to Quill.

From playing around with gmail html emails it appears Google’s strategy is just to treat all linebreaks as <br> for html emails.

I think my ideal would also be similar to @mrcasals vision, but it might also make sense (since this is semi-arbitrary) to just make it an init setting that modifies the behavior of getSemanticHTML() in 2.0 API based on a user’s preference for how to treat new lines.

re [jpike88]: Well that would be a wrong and implementation. The general behavior of all major text editors is that “enter” creates new paragraph and “shift+enter” brakes the line. That is a common standard and it is good to keep it.

The actual problem is somewhere else, and that is the how editor handles the text afterwards and how it wraps in html. No matter what I don’t know why people still talk about this, there is evidently nobody for almost 8 years who cares about this issue from the dev team, unless somebody else will join ans solve it.

I guess the problem it self is well understood, only there is nobody who is willing to solve it.

(Vue-quill, but the underlying issue is the same) My work-around is to change the margins of the <p> inside the text editor.

<div class="container-editor-text>
   <p>Paragraph 1</p>
   <p>Paragraph 2</p>
</div>

.css file:

.container-editor-text {
  p {
    margin-block: 0;
    margin-inline: 0;
  }
}

@walanjvinayak it’s good when that’s a possibility for a project. In our use case, it was a problem and for semantic reasons, we actually did have to use p. It’s almost funny that this issue still exists.

I did this and it works fine for my use case. Note that I’m using Bootstrap 4 so you have to take into account the CSS resets.

.post-content p > br:only-child {
    display: none;
}

You can very clearly type

Joe Smith 1234 Main St Los Angeles, CA

in almost any demo on quilljs.com. This issue is about the particular markup.

@jhchen that’s true that we can type the above text in the editor… but that’s not the issue. The issue appears when we display the html that Quill generates outside of the editor.

Yes it’s still an issue. But this worked for me: https://github.com/zenoamaro/react-quill/issues/513#issuecomment-523783053