Thank you for the many interesting replies, and for helping me see the
problems with using <pre>
The example Spartanicus provided works fine in Safari, although my own
web page does not. My own page also failed in Opera and Firefox.
Leonard Blaisdell probably put his finger on the problem, with the
comment about it not working worth a damn when he wrapped it in a <p>
element. Basically none of my HTML has ever included the (optional)
closing elements for list items or paragraphs. However as part of this
cleanup, I added them. Previously <pre> would have signalled closing of
the previous <p> block element, but now there is a </p> at the end of
the </pre>.
However, finding the <pre> problem came when I had just organised bulk
validation of an entire directory. It is entirely possible that I
changed the pages in question in other ways while correcting other
errors or problems. For example, I did a global addition of </p> to all
paragraphs, however my search for a typical paragraph did not cover all
possibilities, and also added </p> at inappropriate places.
Eric Bustad sees a > prior to </code> that isn't in my source.
MB Stevens raises the point that the new lines I am using inside <pre>
do not show up under Moz/Linux. This gets even more confusing when Stan
Brown reports the source code appearing to him as absolutely nothing
like what I wrote. I have no idea where the ="" that he sees come from.
The eof is simply an unusual word used as the starting point and end
point for a Here document in Bash. It was never intended to show as a
tag.
However both of these point to a serious problem with using <pre> to
show any text that depends on new lines. Bash shell scrips do depend on
new lines. So now I am scratching my head wondering where new lines
went wrong.
My web pages were housed on Unix, where 0x0A ^J or Line Feed (called New
Line and '\n' in C) ends a line.
My pages lived on MS-DOS for many years, where both Carriage Return 0x0D
^M and Line Feed 0x0a ^J are used together.
My pages have now been moved to a Macintosh. Editors seem to be moving
from old Macintosh line endings of 0x0D ^M Carriage Return alone used on
Apple II and through to Mac OS 9. Now Macintosh editors seem to be
moving to just an 0x0A Line Feed. To make this much worse, I have been
editing my pages with a wide variety of editors, while trying to find an
editor I like. I am no longer even sure what treatment has been applied
to any particular file. (Hmm, no man page for hexdump or od - surely a
Macintosh has some sort of file dump?)
Finally, RFC2616 seems to be saying "HTTP/1.1 defines the sequence CR LF
as the end-of-line marker for all
protocol elements except the entity-body (see appendix 19.3 for
tolerant applications). The end-of-line marker within an entity-body
is defined by its associated media type, as described in section 3.7."
Section 3.7.1 says "When in canonical form, media subtypes of the "text"
type use CRLF as
the text line break. HTTP relaxes this requirement and allows the
transport of text media with plain CR or LF alone representing a line
break when it is done consistently for an entire entity-body. HTTP
applications MUST accept CRLF, bare CR, and bare LF as being
representative of a line break in text media received via HTTP."
So it is entirely possible that some of my files have inconsistent
treatment of the line break that I don't know about. This is just
getting more and more wonderful by the minute!
Jukka Korpela correctly points out that I am totally wrong in ever
allowing any < character to get into the <pre> in the first place.
My conclusions. Please feel free to disagree and point out better ideas.
1. <pre> does not work well enough to be used for displaying anything
where line break is significant. That means not using it for code or
poetry.
2. Cutting and pasting code into <pre> was an error - I am going to
fail to notice characters that should be escaped. I should make a
little shell script to turn code snippets longer than a single line into
correct HTML. Specifically, the script should target < > and & and turn
them into character entities (is there anything else to target?)
3. I could use <p><code>Conten t<br>
mor e content<< <br>
</code></p> and style <code> with CSS.
That seems very messy to me, especially the use of multiple
however I can't see many alternatives at the moment.
I could use <pre><code>Cont ent<br>
more content<< <br>
</code></pre>
This assumes <pre> will get white space correct, but fail to get line
breaks OK. If it does get line breaks, then double lines are used,
unless I send the code as one long line of text with no line breaks at
all.
Hmm, or I could enclose every line of every example in its very own
<pre><code> pair (which solves the white space problem) , and use CSS to
reduce the space between each line!
<pre><code>cont ent</code></pre>
<pre><code> content2</code></pre>
<pre><code> content3</code></pre>
That should present OK on any modern browser. Better suggestions would
be most welcome.
--
http://www.ericlindsay.com 
