Opened 9 years ago

Closed 9 years ago

Last modified 8 years ago

#12879 closed Bug (invalid)

Last BR tag inside block element is replaced with  

Reported by: Wiktor Walc Owned by:
Priority: Normal Milestone:
Component: General Version: 3.0
Keywords: Support Cc:

Description

  1. Enter the following text in source mode:
<p>This is normal text<br /><br /></p>
<h1>This is a header<br /><br /></h1>
  1. Switch to wysiwyg mode and back.
  2. Result:
<p>This is normal text<br />
&nbsp;</p>

<h1>This is a header<br />
&nbsp;</h1>

Confirmed in IE11, Chrome, Firefox, enter mode BR and P. CKEditor has been working this way at least since 3.0. Did not check earlier versions.

Looks very similar to #4006 although I don't understand how &nbsp; is better than keeping the original value.

Attachments (1)

brvsnbsp.png (52.4 KB) - added by Piotrek Koszuliński 9 years ago.

Download all attachments as: .zip

Change History (7)

comment:1 Changed 9 years ago by Wiktor Walc

Status: newconfirmed

comment:2 Changed 9 years ago by Piotrek Koszuliński

Status: confirmedpending

This is changed because the content is normalized. Both forms have the same outcome. See: http://jsfiddle.net/fq7t7277/. I don't understand why do you consider it a bug?

Last edited 9 years ago by Piotrek Koszuliński (previous) (diff)

Changed 9 years ago by Piotrek Koszuliński

Attachment: brvsnbsp.png added

comment:3 Changed 9 years ago by Wiktor Walc

Resolution: invalid
Status: pendingclosed

I don't understand why do you consider it a bug?

My findings were exactly the same as yours regarding the lack of visual difference on HTML pages. I marked it as a bug because still the content was changed, which may affect tools like HTML to PDF processors etc.

However, on second thought I tend to agree that you are right. If for HTML it makes no difference, then in case of differences e.g. in PDF documents that would be rather a bug in the conversion tool.

comment:4 Changed 9 years ago by Piotrek Koszuliński

If the content was created by CKEditor there would be no difference, because CKEditor is consistent in what it produces. The problem appears when loading something what was not created in CKEditor. Such content must be normalised, otherwise its editability could be harmed.

PS. I believe that in this case it should be possible to turn br+nbsp into two brs by some simple regexp applied before sending such content to PDF processor. There simply should be a processor adjusting CKEditor's output to such external lib's characteristic.

Last edited 9 years ago by Piotrek Koszuliński (previous) (diff)

comment:5 in reply to:  3 Changed 8 years ago by wginolas

Replying to wwalc:

My findings were exactly the same as yours regarding the lack of visual difference on HTML pages. [...]

Actually there are visual differences:

<table align="left" border="1" cellpadding="1" cellspacing="1" style="width:100%">
	<tbody>
		<tr>
			<td>&nbsp;</td>
		</tr>
	</tbody>
</table>

<p>&nbsp;</p>

<p>Test</p>

In this HTML snippet both paragraphs are placed below the table. When the CKEditor replaces the &nbsp; with an <br> in the first paragraph, the p tag will placed right of the table.

This results in the following Problem:

  1. User sees a space between "Test" and the table.
  2. User opens the CKEditor to remove the space.
  3. The space disappears. -> User is confused.
  4. User closes the CKEditor.
  5. Space reappears. -> User is frustrated.

comment:6 Changed 8 years ago by Jakub Ś

@wginolas please see #11392 and especially #10146.

Note: See TracTickets for help on using tickets.
© 2003 – 2022, CKSource sp. z o.o. sp.k. All rights reserved. | Terms of use | Privacy policy