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




17 years ago
5 years ago


(Reporter: shd, Unassigned)



Firefox Tracking Flags

(Not tracked)





17 years ago
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:

Comment 1

17 years ago
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.

Note the first point:
    * May leave white space intact.

Combine that with the quote below.

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.

I think this bug is invalid
Last Resolved: 17 years ago
Resolution: --- → INVALID

Comment 2

17 years ago
_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.
Resolution: INVALID → ---
Summary: CR is considered LF in <pre> blocks → [QUIRK]CR is breaks line in <pre> blocks, but not in IE
Ever confirmed: true


17 years ago
Target Milestone: --- → mozilla1.2

Comment 3

17 years ago
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

17 years ago
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;


#include "LinuxThread.h"

typedef LinuxThread Thread;

// 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

17 years ago
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...
Summary: [QUIRK]CR is breaks line in <pre> blocks, but not in IE → [QUIRK]CR breaks line in <pre> blocks, but not in IE

Comment 6

16 years ago
*** Bug 182470 has been marked as a duplicate of this bug. ***
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.
Assignee: attinasi → other
QA Contact: petersen → ian
Target Milestone: mozilla1.2alpha → ---
I will take this sin upon my soul.  ;)  WONTFIX.
Last Resolved: 17 years ago15 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.