#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
- Enter the following text in source mode:
<p>This is normal text<br /><br /></p> <h1>This is a header<br /><br /></h1>
- Switch to wysiwyg mode and back.
- Result:
<p>This is normal text<br /> </p> <h1>This is a header<br /> </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
is better than keeping the original value.
Attachments (1)
Change History (7)
comment:1 Changed 10 years ago by
Status: | new → confirmed |
---|
comment:2 Changed 10 years ago by
Status: | confirmed → pending |
---|
Changed 10 years ago by
Attachment: | brvsnbsp.png added |
---|
comment:3 follow-up: 5 Changed 10 years ago by
Resolution: | → invalid |
---|---|
Status: | pending → closed |
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 10 years ago by
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.
comment:5 Changed 9 years ago by
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> </td> </tr> </tbody> </table> <p> </p> <p>Test</p>
In this HTML snippet both paragraphs are placed below the table. When the CKEditor replaces the with an <br> in the first paragraph, the p tag will placed right of the table.
This results in the following Problem:
- User sees a space between "Test" and the table.
- User opens the CKEditor to remove the space.
- The space disappears. -> User is confused.
- User closes the CKEditor.
- Space reappears. -> User is frustrated.
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?