Proper client interpretation of <pre>blah</pre>
cheung@eplrx7.es.dupont.com (Bryan Cheung)
Date: Tue, 2 Nov 93 10:15:10 EST
Message-id: <9311021515.AA10330@eplrx7.es.duPont.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: www-talk@nxoc01.cern.ch
From: cheung@eplrx7.es.dupont.com (Bryan Cheung)
Subject: Proper client interpretation of <pre>blah</pre>
I have noticed some differences in the way that w3 clients interpret the
<pre>blah</pre> clause. It seems that some X,Mac-mosaic, and Cello
ALWAYS insert a newline after <pre>blah</pre>, whereas Lynx does not.
What is the proper behavior?
I encounter the problem in the scenario described below. I welcome
any and all advice on better HTML techniques -- I am a beginner.
I am trying to set up a table of the form:
Column1 Column2 Column3
===========================================
Value11 Value12 Value13
Value21 Value22 Value23
Value31 Value32 Value33
...
Valuen1 Valuen2 Valuen3
===========================================
Generated by
Column1 Column2 Column3
===========================================
<inc srv "/here/row1.html">
<inc srv "/there/row2.html">
...
<inc srv "/there/rown.html">
===========================================
Where each "rown.html" can be included in multiple tables, and looks like:
<pre>Valuen1 Valuen2 Valuen3</pre>
and contains *NO* newlines. Note that many of the ValuenX values may
be hypertext links.
In XMosaic, Mac-mosaic (NCSA), and Cello, the display resulting from
the above setup is:
Column1 Column2 Column3
===========================================
Value11 Value12 Value13
Value21 Value22 Value23
Value31 Value32 Value33
...
Valuen1 Valuen2 Valuen3
===========================================
In Lynx I get:
Column1 Column2 Column3
===========================================
Value11 Value12 Value13
Value21 Value22 Value23
Value31 Value32 Value33 <--strange collapsed white space
Value41 Value42 Value43
Value51 Value52 Value53
...
Valuen1 Valuen2 Valuen3
===========================================
Any clues or help is greatly apreciated.
-- Bryan Cheung
cheung@eplrx7.es.dupont.com