Re: The <PRE> tag
Tim Berners-Lee <timbl@www3.cern.ch>
Date: Thu, 26 Nov 92 10:32:36 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-id: <9211260932.AA01230@www3.cern.ch>
To: jim@wilbur.njit.edu (Jim Whitescarver)
Subject: Re: The <PRE> tag
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch
> Date: Wed, 25 Nov 92 12:41:49 est
> From: jim@wilbur.njit.edu (Jim Whitescarver)
> We are not stuck on the <PRE> tag, only the functionality. If <p> at
> the end gave us single spaced output, that would be acceptable though a
> bit more work. I've been unable to duplicate the effect using existing
> tags. Whatever name, (I'd prefer <PREFORMATTED>),
PREFORMATTED is too long for default SGML element length.
I feel FIXED is more descriptive of what the tag means -- in that the character
spacing is fixed. I feel the tag should describe the interpretation to be but
onto the data, not just its origin. In fact, FIXED would be used in cases where
XMP and LISTING are used now. It is trivial to convert. I so no great use for
XMP and LISTING except for back-compatibility.
WIDTH
I would like an attribute WIDTH=nn to specify the width of display.
This can allow the viewer to select a font which will fit. It will also
allow something 40 chars wide to be indented rather than having to
start at the LH margin (and typically be filled out with tabs so that it
doesn't look silly) like in a quoted command. I would put an implementor's
comment in that widths of 40, 80 and 132 are likely and handling those well
would be a good move. Any oethr widths can be rounded up of course.
In a style-oriented editor, that gives 3 styles: command, example,listing.
> the standard should
> include an end tag </PRE>. We don't support an end tag, but should.
Definitely!
> I
> attampted to translate ms documents to html, with some success, but,
> equations (neqn) and tables (tbl), were close to impossible. I'd like
> to use preformatted for those sections alone, and not the whole document
> (http://eies2.njit.edu/rakesh/paper.html).
I get "Document address invalid or access not authorised" for
that one ... have you sepelt it right?
NEW LINE
Whether lines are ended with newline or <p> is in fact a question of
practicality.
> The idea of new lines being significant is only repungnant in the case
> of generating new hypertext. The express purpose of <PRE> is to make
> use of externally formated text where new lines ARE significant.
Hold on. Let's get our ideas straight. We want FIXED to allow us
to inlcude preformatted text. We can never, however, just paste preformatted
text into a <PRE> section because we will have to change the < and & characters
to entities. At the same time as we add those it's easy to add a <p> at the
end of every line.
It isn't just mail which has problems with newlines. There are horrible
mainframe systems which have trouble with things which don't fit into card or
lineprinter images, and even VMS complains when a line buffer overflows. There
are probably a lot of finite line buffers in the world. When you imagine
(pathalogical case) putting an anchor on each of 80 characters, we can end up
with of the order of 1kB per line. When it totally resonable for you and me but
I bet someone will hate it.
But then of course we can always break lines before any tag closer > so it
doesn't matter anyway, right?
Dan's aygument remains that by SGML convention (only?) newlines are significant
only in "RCDATA" (replacable character data) in which one cannot have anchors.
If you need anchors, you need PCDATA (parsable CDATA) in which newlines are
by convention not signifiant.
> I used the <p> tags within <PRE> text in order to marginally support
> browsers that do not understand <PRE>. I'll be glad to provide a
> version of manual pages without the <p>, http://eies2.njit.edu:1234/man-p.
> The long term value of mixing <p> within <PRE> is dubious at best.
I absoltely agree that we don't mix <p> with significant newlines!
My attempts to interpret your man pages lead to a lot of white
space, as \n<p>\n was interpreted as 3 newlines!
Let's not bother marginally supporting any browsers. All the parser authors are
in this discussion, we can get it right and define it. We can then all
retrofit it in time for the MIME text/html definition. OK?
I would like to see a /man/fixed with either <p> throughout or no <p>.
<FIXED>
Every line ends with <p><p>
<p>
Blank or not<p>
</FIXED>
> The MidasWWW update for <PRE> looked nice and simple. I look forward
> to trying it!
>
> Let's get a <PRE> capability into the standard so we can put anchors
everywhere!
Absoltely. We just need discussion or votes on 3 issues:
Tag name: <FIXED> <PRE> (other)
Newlines: \n <p>
WIDTH=nn yes no
>
> jim
>
Tim