PRE and Line Breaks

[anonymous]

When I choose "Formatted" format and then write some text containing new line characters and/or indentation (tabulations) I get the incorrect html code.

I used FCKeditor 2.0 FC.

I wrote:

This is my first line.
This is indented text.

Then I clicked on "Source" button in FCK and I got the following html code:

<pre>This is my first line.<br/>
This is indented text.</pre>

First of all there is no indentation. Secondly, the PRE element tells visual user agents that the enclosed text is "preformatted", so there should be no html tags (e.g. BR) in it. It should be just what I had written with tabs and new line characters.

Thirdly, switching between source and editor (pressing "Source" button) increases number of BR tags. When I clicked for the first time I received only one BR, but after next click I got 2 BR tags, then 4 BR tags and so on. This is what I got after three switches between "Source" and editor:

<pre>This is my first line.<br/>
<br/>
<br/>
<br/>
This is indented text.</pre>

---

Moved from SF:
​http://sourceforge.net/tracker/index.php?func=detail&aid=1209755&group_id=75348&atid=543653

[Frederico Caldeira Knabben]

The workaround for this is to set

FCKConfig.FormatSource = False;

This does make it much harder to edit the source but at least it does not add lots of <br/> tags.

---

Moved from SF. Original poster: jaydaley

[Frederico Caldeira Knabben]

I just went to the online demo and tried to reproduce your problem there:

• There were no BR duplication. If you still have the problem, please provide us the precise steps to reproduce it.

• It is not a problem to use BR tags inside PRE. It is part of the W3C specifications. I just tested it and it has been validated even over the XHTML 1.0 Strict. So you should not have problems with it.

• It is necessary to have the BRs inside the PRE, otherwise, if you revert the paragraph to "Normal" (P), it will not have explicit line breaks, and so you will have all lines merged in one.

Let us know if you still have problems with it. be sure you have the latest version.

---

Moved from SF.

[Frederico Caldeira Knabben]

The following code partially reproduces the error in the demo. Go into the source view and enter this

<pre>First Line<br/>
Second Line<br/>
Third Line<br/>
</pre>

which the sample editor then overrides as

<pre>First Line<br /><br />Second Line<br /><br />Third
Line<br /><br /></pre>

Using the version of FCK built into infoglue, doing the same thing I get

<pre>First Line<br/>
<br/>
Second Line<br/>
<br/>
Third Line<br/>
<br/>
</pre>

and each time I repeat it, more <br /> are added. So you can see these are the same bug but in the more recent version of the editor it does not format the source the same and so the bug only affects it once.

Now <pre> sections are used where you want to display things exactly as they appear. In our case it is to show the output of a program. So having it changed is very awkward. Also when people copy and paste this text from IE it comes out on one line rather than as it was entered.

I would like to see FCKeditor leave <pre> (and <code>?) sections intact without any formatting of them taking place. This is the expected behavior.

---

Moved from SF. Original poster: jaydaley

[Frederico Caldeira Knabben]

I'm still not able to reproduce the problem.

I went to the demo and pasted that code. Switching through WYSIWYG and Source, leaves the contents intact.

Also, you are in some way forcing the error here. You have actually two line breaks for each line with that source. One is the <BR>, the other is the "line break" at the end of each line. So, if you have two <BR> you will have the same output results.

Cut and paste operations are always problematic on target applications. For example, when using Visual Studio, if you copy something from a HTML source (like FCKeditor, or any web page), it will paste the HTML present inside it. In this cases, you have to use the "Paste as HTML" feature of Visual Studio. In any case, it will not give always good results.

One think that we could think about would be a new features called "Copy as Text", that would retrieve the editor selection as plain text. But this is all work to be done and would categorize this report as a "Feature Request".

---

Moved from SF.

[Frederico Caldeira Knabben]

OK I checked. In the demo this only happens if you use Firefox, not IE. With IE it leaves the text completely untouched. In fact IE leaves untouched the following

<pre>First line
second line
third line</pre>

I understand about line breaks (i.e. CR+LF, not <br/>), but my point is that browsers handle line breaks in <pre> differently, by actually displaying them, which is why we need them preserved. For example if you view the code above in a browser then it will show the line breaks, but the following code will not.

<p>first line
second line
third</p>

Which is because browsers ignore line breaks in anything other than <pre> sections. This is why cut and paste is expected to work with <pre> sections.

Just to be clear I want to enter <pre> section like the one at the top of this comment, with line breaks not <br/> where the line breaks are preserved and no <br/> are added.

Thanks for taking the time to discuss this.

---

Moved from SF. Original poster: jaydaley

[Frederico Caldeira Knabben]

Ok... I'm reopening the bug. Let's see if something could be done on future versions... no promises. Maybe something configurable, because it is a requirement for you, but not on all cases.

Thanks for the precise explanations Jay.

---

Moved from SF.

[Frederico Caldeira Knabben]

Thanks for looking into this, but let's look at this another way. Go into any other HTML editor and enter the following in the source view:

<pre>First line
second line
third line</pre>

Then go back to WYSIWYG, then back to source view. In both Dreamweaver and Frontpage the code is untouched by the WYSIWYG engine. The reason is not that adding the breaks is invalid, it's because the intention of the <pre> tag is that the code is preformatted, meaning that it does not require additional editing or formatting. By introducing additional breaks where the author has not requested them, FCKeditor has not honored the author's intention for the code.

Here's what O'Reilly HTML Reference says about the <pre> tag:

"Preformatted text is usually rendered by default in a monospace font, and more importantly, it preserves the white space (multiple spaces between words and new lines) entered into the source code for the content."

I understand your comment about "<br />\n" actually being two newlines. However, while technically true, it is not consistent with the preformatted text specification, which is intended to preserve new lines as the author entered them.

Further, O'Reilly says, "Browsers are supposed to ignore a whitespace line break immediately following a pre element tag in case you wish to start the content on a new line in the source editor." Here again, if I enter in to the FCKeditor source mode:

This
is
a
sentence

...it should be rendered as "This is a sentence" to the browser, not as "This\nis\na\nsentence", which is what FCKeditor does now. In this way, the editor has not only not honored the spirit of the preformatted tag, it has violated the W3C convention.

Can you please reconsider the <pre> tag's behavior?

---

Moved from SF. Original poster: jefflv

[Frederico Caldeira Knabben]

Of course I'll reconsider it. The only thing is that the actual behavior is performed by the browser itself and not FCKeditor. So, there would be much work to be done to change it to behave in the way you've described.

I really hope FCKeditor will work someday exactly like Dreamweaver, and I'm working hard on it... but, remember that we are talking about an JavaScript interpreted application against a compiled Desktop one.

Also I'm still not able to reproduce the "doubled" line break. I went to the demo, and typed:

First line<SHIFT+ENTER>second line<SHIFT+ENTER>third 
line<SHIFT+ENTER>

The output I have with it is:

First line<br />second line<br />third line<br />

And I can switch back to source as many times I want and I have always the same result.

So for now, the author would be ok, as the output would be exactly how he/she wanted, even if the HTML is not exactly how you want.

It would be quite easy to "replace" all occurrences of the <br /> with a "\n", but the problem would be when reopening the text in the editor and then trying to change it from <pre> to <p>. As we don't have BRs, everything would be rendered in a single line (as well described by you). So we have to write code to handle these situations and add the BRs again.

We'll as you can see, we have many work to be done here to accomplish it. At least now we have a clear knowledge about the problem.

Thanks again.

---

Moved from SF.

[Frederico Caldeira Knabben]

But you have duplicated the error. The output: "First line<br />second line<br />third line<br />" is incorrect because the author did not enter "<br />" anywhere in the code, and "\n" cannot be automatically changed to "<br /> within a <pre> tag because that is not what the author intended, nor what the specification allows.

I believe the goal here with the source view, it to allow an author who is knowledgeable about (X)HTML to enter code that conforms to the specification. Using heuristics to change "\n" to "<br />" is helpful only if you assume that the HTML author does not know what he is doing, and does not fully understand the specification. This is a tricky case, because if he does fully understand the specification, FCKeditor goes behind his back and changes his code in a manner that is not intended, and is out of conformance with that specification.

Previously, you said, "It is necessary to have the BRs inside the PRE, otherwise, if you revert the paragraph to 'Normal' (P), it will not have explicit line breaks, and so you will have all lines merged in one." The answer is: they *should* be merged into one because that's what the W3C specification for the pre tag dictates.

Okay.....all that being said, I am grateful for being allowed to use this editor with it's current license, and am grateful for all the hard work that's been put into it. I am a software engineer, so I really appreciate what you're going through, and I understand that what I'm asking in this regard may be difficult to implement, regardless of the question of whether it implies conformance with the standard.

Jeff

---

Moved from SF. Original poster: jefflv

[Frederico Caldeira Knabben]

Just to clarify avoid doubts to who's reading this interesting discussion.

It is not a problem to use BR tags inside PRE. It is part of the W3C specifications. I just tested it and it has been validated even over the XHTML 1.0 Strict. So the code generated by FCKeditor "is" under the XHTML specifications.

The O'Reilly HTML Reference is not a specification. It is just a reference. And we agree with that reference when it is said that if you have "\n" inside a PRE, it must be rendered as a line break. And actually FCKeditor does that when "loading" HTML with a PRE with "\n"s. There is nothing in the reference saying that you cannot have BR tags inside PRE.

With FCKeditor, for now, when pressing the <Enter> key inside a PRE, a BR tag is added instead of a "\n". Both methods are ok for the specifications, but we don't support the second one.

We understand that some users would prefer having "\n" and not BRs inside PRE, while others don't care about it. And probably we don't have people that would prefer BRs instead of "\n". So to make everybody happy, we should change the current behavior and adopt the "\n".

We just have to pay attention to the implementation. The great majority of our users, just want to type a line, hit enter, and type another line. The don't care about the code produced and so they would expect that, when changing another block format, the "line breaks" would remain untouched.

---

Moved from SF.

[Frederico Caldeira Knabben]

I would love to agree with you here, but your response is misleading. :-) And my apologies for my obtuseness.

The question is not whether the output produced by FCKeditor meets XHTML 1.0 Strict; it does. The question is whether it is correct; it is not!

Example: if I type "Me & Sarah" into the code view and FCKeditor renders this as "Me &gt; Sarah", the output meets XHTML 1.0 Strict but is incorrect because "&gt;" does not equate to "&". Conformance is not the issue, correctness is.

You took issue with the quote from O'Rielly; fair enough. Here's the W3C specification for preformatted text (​http://www.w3.org/TR/REC-html40/struct/text.html#edef-PRE):

"The PRE element tells visual user agents that the enclosed text is 'preformatted'. When handling preformatted text, visual user agents:

• May leave white space intact.
• May render text with a fixed-pitch font.
• May disable automatic word wrap.
• Must not disable bidirectional processing."

Additionally, "white space" is defined as (​http://www.w3.org/TR/REC-html40/struct/text.html#whitespace):

• ASCII space (&#x0020;)
• ASCII tab (&#x0009;)
• ASCII form feed (&#x000C;)
• Zero-width space (&#x200B;)

So the question to me is, "Does FCKeditor leave white space intact?"

Let's do a test. In code view *paste* the following:

<pre>
	Hello!    My
	name
	is
	Jeff
</pre>

After saving source and going back into source in the Demo we get the following:

<pre>Hello!    My<br />name<br />is<br />Jeff<br /></pre>

This is correct two ways. First, the multiple spaces were left intact - not replaced with multiple "&nbsp;", for example. Second, the tab characters were left intact - also not replaced with some other convention.

However, it is also incorrect in two ways. First, the newline characters were not left intact, they were changed to "<br />". As mentioned previously, this is contrary to W3C section 9.3.4 on Preformatted Text (URL above). Second, adding the "<br />" before the "</pre>" is contrary to W3C section B.3.1 Line breaks (​http://www.w3.org/TR/REC-html40/appendix/notes.html#notes-line-breaks), which says, "SGML (see [ISO8879], section 7.6.1) specifies that a line break immediately following a start tag must be ignored, as must a line break immediately before an end tag. This applies to all HTML elements without exception." Since the SGML is the parent schema for all markup languages, it must be respected in all versions of HTML, XML, etc. So in my opinion, the fourth occurrance of "<br />" is incorrect on both points.

I understand your concern with meeting what users expect; that is very important when publishing software. And as long as the casual user stays in the WYSIWYG, when they hit enter they get a break on the page, which is as it should be, as you said, "they don't care about the code". However, the moment a user enters the source code they are declaring loud and clear, "I do care about the code, and this code follows rules as published by the W3C, and that's what I expect." Something fundamental has changed: the user expectation. What's happening now is that the source code view is acting like a WYSIWYG instead of the markup it is.

Last thought: My intention was not to compare FCKeditor with Dreamweaver or FrontPage. My intention was to point out that within the industry of web designers, there's already a very clear expectation in regards to what happens with preformatted text. In other words, you may disagree with my interpretation of these W3C texts, but I'm in good company.

Again, thank you for your consideration. I very much respect your opinion and your product.

Jeff

---

Moved from SF. Original poster: jefflv

[Frederico Caldeira Knabben]

(Ring! Ring!)

We have a few issues here. The most important is the white space removal (not the line breaks) because it produces an output that is different of what the user wanted it to be.

Actually the Code Formatter is removing white spaces in the beginning for lines inside PRE tags. This is a major bug.

I've just made an attempt of fixing it for the upcoming 2.2 version. Whenever possible, I would ask all you to please take a look at the following page and make some tests:
​https://sourceforge.net/forum/forum.php?thread_id=1406350&forum_id=379487

Please leave any note regarding that Preview version in that thread.

With IE you have precise code preservation now for those tags. Firefox automatically converts all "\n" to BR.

On both browsers, BR tags will be generated when hitting enter, which is XHTML compliant and gives the desired rendering output.

Once release the 2.2 (tomorrow), we still have to work on the following issues:

• Make the editor produce "\n" when hitting <Enter> inside PRE tags.

• Manage block formatting switching, adding BRs when switching from PRE and replacing them with "\n" when switching to PRE.

---

Moved from SF.

[Frederico Caldeira Knabben]

In firefox the conversion of \n to <br> is due to ​https://bugzilla.mozilla.org/show_bug.cgi?id=92921

---

Moved from SF. Original poster: alfonsoml

[Frederico Caldeira Knabben]

#402 is a DUP of this one.

[Martin Kou]

Fixed with [525].

Click here for more info about our SVN system.