98356 - [QUIRK]CR breaks line in <pre> blocks, but not in IE

Status: RESOLVED WONTFIX

(Core :: Layout, defect)

Description

[Steven Don]

I've put up a little test at the URL: http://www.zzict.nl/~steven/
(don't leave out the trailing '/').

Other browsers start a new line in a <pre>..</pre> block only when they
encounter LF or CR/LF combinations. CR in itself should not start a new line.

I'm not sure what the HTML specs say on this, but it definitely makes the code
listings on flipcode difficult to read.

For example, see:
http://www.flipcode.com/cgi-bin/msg.cgi?showThread=Tip-CodingLayoutForPlatformIndependence&forum=totd&id=-1

Comment 1

[basic]

http://www.w3.org/TR/html4/struct/text.html#edef-PRE
<quote>
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.

</quote>
Note the first point:
    * May leave white space intact.

Combine that with the quote below.

http://www.w3.org/TR/html4/struct/text.html#line-breaks
<quote>
A line break is defined to be a carriage return (&#x000D;), a line feed
(&#x000A;), or a carriage return/line feed pair. All line breaks constitute
white space.

</quote>
I think this bug is invalid

Comment 2

[Marc Attinasi]

_basic, your research is great, but IE is in some ways a de-facto standard, so
at least we need to consider this in Quirks mode. From the referenced
specifications, this is fine for standard mode...

Updating summary and reopening.

Comment 3

[Andrew Hagen]

Old Summary: [QUIRK]CR is breaks line in <pre> blocks, but not in IE
New Summary: [quirks] CR is breaks line in <pre> blocks, but not in IE

Comment 4

[Bartosz Wucke]

Well, IE is a standard in the same degree as CR+LF is the newline standard.
Mozilla's philosophy is to follow the official standards of w3org, not fancies
and mistakes of Microsoft. In my opinion, this is a bug in MSIE, not in Mozilla!
Note, this would completely break all the pages that were composed under Unix
and use just CR as newline.

In the testcase given everything is correct: "CR" or "LF" are interpreted as
newline (just as PRE standard says) and then additional TWO newlines are added,
one generated by the BR tag and one by the EOL (CR or LF) at end of line after
BR. In the case without PRE EOLs are correctly ignored and BR correctly breaks
the line.

Note, "fixing" that bug would completely break all the pages using <pre> that
were written on Unices, where all the EOLs are CR. It's buggy server software
that inserts BR on newlines inside of PRE tags, where it's not required.
Even if we compare both cases, say yourself, which piece of code do you like more?
Current, produced by buggy servers:

----------------------------
// file : Thread.h

#if defined( WIN32 )

#include "WinThread.h"

typedef WinThread Thread;

#else

#include "LinuxThread.h"

typedef LinuxThread Thread;

#endif
// WIN32



// file : WinThread.h

class WinThread {};



// file : LinuxThread.h

class LinuxThread {};
------------------------------
Or one that would be produced from source code literally entered between PRE
tags with CR ignored:
------------------------------
// file : Thread.h#if defined( WIN32 )#include "WinThread.h"typedef WinThread
Thread;#else#include "LinuxThread.h"typedef LinuxThread Thread;#endif// WIN32//
file : WinThread.hclass WinThread {};// file : LinuxThread.hclass LinuxThread {};
-----------------------------

I vote against this fix.

Comment 5

[Steven Don]

As far as I know (it's certainly true on my system), Unix uses LF for a newline,
not CR. I know of no pages that contain <pre> blocks that display incorrectly in
IE, as much as I despise that browser. Do you have any examples?

At any rate, perhaps this behaviour should be configurable...

Comment 6

[Josh Birnbaum]

*** Bug 182470 has been marked as a duplicate of this bug. ***

Comment 7

[Christopher Hoess (gone)]

Lone "CR" is the Mac-specific line break, not Unix. Given the lack of duplicates
to this bug (I discovered the one duplicate to be incorrect), I propose it be
closed as WONTFIX.

Comment 8

[Boris Zbarsky [:bzbarsky]]

I will take this sin upon my soul.  ;)  WONTFIX.