Sceditor adds extra new lines

[jetand]

Hi. I'm trying to solve the following problem:

Input:

Line 1 new line with return key Line 2 new line with return key Line 3

select all and click bold -> save

Server gets the following data

[b]Line 1[/b]\r\n[b]Line 2[/b]\r\n[b]Line 3[/b]

This is fine.

Now add a new empty line after Line 1 and Line 2. Server gets back the following

[b]Line 1[/b]\r\n\r\n\r\n[b]Line 2[/b]\r\n\r\n\r\n[b]Line 3[/b]

Problem: Where did the extra new line come. Now there are two extra lines after Lines 1 and 2 instead of one extra line.

Page reloaded:

<div><strong>Line 1</strong><br /></div> <div><br /></div> <div><br /></div> <div><strong>Line 2</strong><br /></div> <div><br /></div> <div><br /></div> <div><strong>Line 3</strong></div>

User now sees extra lines that he or she did not put there. Making more changes and saving again increases the amount of new lines after every save.

Any idea how to fix this extra empty new line problem?

[JimCook57]

I am having the exact same issue.

[jetand]

Good to know @JimCook57 . This is really frustrating for customers who edit their documents multiple times. They get a whole lot of whitespace in their documents. I haven't found a fix to this.

[brunoais]

OK. I analyzed on the latest stable of IE, chrome and firefox. My conclusion is that chrome and IE agree that <Enter> means new paragraph and <shift> + <Enter> means new line. In firefox, however, <Enter> and <shift> + <Enter> means new line if the cursor is not inside a block element, otherwise, it's a new paragraph.

The way a new paragraph is made depends on the containing tag. By default, all seem to be doing the new paragraph using a clone of the current tag. What it seems to me is that, in general, people use <Enter> as if they were using (and with the intention to use) <shift> + <Enter>. The main thing that is for sure is that all the browsers tested agree on what to do is when <shift> + <Enter> is pressed.

In Plain text, new lines are represented by \n (or \r\n) and new paragraphs are represented by \n\n (or \r\n\r\n).

My conclusion, @jetand , is that you are making paragraphs between those lines and not new lines. But then, when you do new lines in WYSIWYG, it is translating to new lines in BBCode mode that are translated back to double paragraphs when back to WYSWIYG. So pls try the following: Make new lines instead of new paragraphs and test the result. See if it is doing as it should from your POV. I'm not removing your right to say it is doing it wrong but please try it.

[jetand]

Thank you for your response @brunoais . I tried what you wrote and yes it is like you said. If you make a new line with Shift+Enter it does not create extra new lines anymore. But this is surprising behaviour in my point of view.

[brunoais]

@jetand That, actually, is on-par with all other WYSIWYG text editors such as Ms Word, OO Writer, Lo Writer and all other that are descendants or based from those.

Now, without thinking much, sounds like what I can do is to make an option that overrides the browser's <Enter> into <shift> + <Enter>. All browsers seem to be in agreement on how to behave before a <shift> + <Enter>, so it should be straight forward. Are you OK with that?

[jetand]

Hi again. Yes I understand now that Enter creates a new paragraph and Shift Enter makes a new line. Making new lines with empty paragraphs is a bitty silly I realize now.

But I would guess 99% of our users use Enter to put vertical space between text in our web app and in office products. How would one even notice the difference when composing the message? In MS word there is by default a clear difference in space between newlines and paragraphs. In this editor the space between lines looks the same whether you use Enter or Shift+Enter. A little bit history.. Earlier the message area in the picture was only a textarea element and people are used to put in new lines with just enter. Later we added this editor. We didn't even know about the Shift+Enter possibility until just now. Is it even documented anywhere in the docs? Or is it an undocumented feature? The problem is not just when writing into blank documents but people paste stuff from word documents where they have used Enter as new line and this creates same problems, but that's another story. One thing at a time...

Yes, please send me a code example how I could prevent this unintentional addition of vertical space in the editor. Thank you for your help.

[brunoais]

Making new lines with empty paragraphs is a bitty silly I realize now.

I'm still trying to understand why Sam decided to make paragraphs using <div> instead of <p>. The only thing I can think of is the complaints of people that copy and paste text from OO Writer & cia. In markdown, you use double <Enter> for a paragraph because that's how you say it is a paragraph in plain text... I guess that can be made the same way in SCE in both modes.

Is it even documented anywhere in the docs?

It is documented in the browsers' docs.

please send me a code example

There's nothing yet.

Ok. I made this: http://jsfiddle.net/Mx8ps/ http://jsfiddle.net/Mx8ps/1/ (it is based on someonelse's fiddle)

See how those 2 feel. Which one seem more natural to you for the WYSIWYG? (use both <Enter> and shift + <Enter>)

[jetand]

I've reinvestiged this problem more and now I realize it is not the Enter keypress making a paragraph causing the problem. It is something else. For example if you select three lines, bold them and save you see a different result after page reload.

$('.sceditor').val() Line 1 Line 2 Line 3

$('iframe').contents().find('body').html() <div>Line 1<br></div> <div>Line 2<br></div> <div>Line 3</div>

Select all and click bold

$('.sceditor').val() [b]Line 1 [/b] [b]Line 2 [/b] [b]Line 3[/b]

$('iframe').contents().find('body').html() <div><b>Line 1<br></b></div> <div><b>Line 2<br></b></div> <div><b>Line 3</b></div>

Save now after page reload we get the following

$('.sceditor').val() [b]Line 1 [/b] [b]Line 2 [/b] [b]Line 3[/b]

$('iframe').contents().find('body').html() <div><strong>Line 1<br></strong><br></div> <div><strong>Line 2<br></strong><br></div> <div><strong>Line 3</strong></div>

Now there is an extra br between strong and div even though the bb-code is the same as before saving. These extra br tags cause the extra visible vertical space, if I remove those for example with developer tools then the output is what we expect to see.

[brunoais]

The problem here seems to be the <br> tag just before the </div> closing tag. It seems to be breaking the parser's ability to act properly. For a change, chrome is the one that does it right.

I'll take a look and see if this is caused by SCE's code or if it is, as I think, the browser's own internal code. If it is the browser's internal code, then I'll look into a way to turn it around.

[jetand]

Thank you. Much appreciated! I'll try look into it too and on the same learn a bit more about how the editor works.

[samclarke]

I've just been looking into this. There's an error in the HTML to BBCode converter. Currently it assumes any block level element that is inside an inline element must cause a line break.

This is true expect for when there is nothing after it, eg:

<block>text<inline><inline>text text<block /></inline></inline></block>

The block that is inside the inlines above shouldn't cause a line break (unless the block is a <br /> and the browser is IE < 11).

I've created a fix I just need to do some more testing in to make sure it works correctly in IE.

[brunoais]

Hey Sam! I was thinking on making code that, inside block elements, removes <br> if they are the last node inside the block element. (I didn't know <br> is a block element :). We learn every day...). As you are the original author, you should know better how to deal with that. If you want suggestions, just ask.

[samclarke]

I'm not sure if <br> is treated as a block by browser engines, I think they might have some special handling for it, but as far as SCEditor is concerned it's a block since it acts the same as an empty block most of the time.

For instance:

<div>test<div></div>test</div>

causes a line break just like a <br> and:

<div><strong>test<div></div></strong></div>test

also suffers from this double line breaking bug.

The exception to this rule is IE < 11 where <br> always causes a line break regardless of if there is anything after it. Being IE there is an exception to this exception in that if the block is empty it doesn't cause an extra line break until the block ceases to be empty. That's one of the reasons why there's code in SCEditor to detect IE.

Removing the last block would work. My solution is, instead of removing the last block, to just not add a line break after it. That works everywhere except IE < 11 which still needs fixing.

[brunoais]

Hum... I c... Yeah... complicated matter... There's no spec on how this should behave so each one of the engines creates the same visual result differently. Thanks for the feedback.

[samclarke]

@jetand Thanks for reporting! This should now be fixed in the dev branch.

@brunoais I think there might be a spec for this but either way IE decides to ignore it when contentEditable is enabled.