This file illustrates the actual proper use of the <PLAINTEXT> element,
or "tag," as it was used in the original conception for HTML, and clear
through version 3.2. This element served to enable the web designer to convert
a text file (of which there were many on the internet, far more even than there were
HTML files during the early days of formulating HTML) to HTML in an easy and quick
manner. Instead of having to go through and convert the whole file, a small amount
of HTML, ending with the <PLAINTEXT> tag, could be affixed to the
beginning of the text file, giving it HTML capabilities. In this HTML portion one
could put, for example, a nice title header (and put the title of the document in
the window frame at the top with <TITLE> and
</TITLE>), author notices, <ADDRESS>
information, links to the author's web page and/or e-mail address, or even links to
any footnoted research sources as may be also found on the web. For example, to
convert a historic ASCII text file (such as RFC 1111) one could
just add some HTML functionality to the front and then append the text file after a
<PLAINTEXT> tag, resulting in this.
(In addition, for validity concerns, I replaced a number of ASCII form feed
characters with the expression [VT] using a global substitution.)
This shows <PLAINTEXT> to be substantially different from
<XMP> (or <LISTING>) in that where they serve
to enable the web page programmer to insert raw text anywhere into an HTML file
<PLAINTEXT> is for adapting plain text files to HTML. But it does
have in common with them the fact that it causes text to be displayed in a strict
monospace format identical to them, and also suffers the same limitations with
respect to the possibility of non-SGML constructs being in the text that follows
<PLAINTEXT>.
An example of an HTML file using <PLAINTEXT> has been found
here on the W3C
archives. There is a report of the Erwise user agent being modified in February of
1991 to accomodate this tag showing that it too seems to have existed from practically
the beginning of the January 23, 1991 - November 23, 1992 period of HTML. With HTML
versions from the oldest surviving DTD to 1 through 3 of the of HTML specification,
the <PLAINTEXT> element (along with the <XMP> and <LISTING> elements) was depreciated. Notice how
HTML 2 survives now in four basic varieties, two of which accept, and the other two of
which are Strict and do not tolerate, this non-SGML-compliant tag, but of HTML 3.2,
only the non-strict version has its own DTD declaration (which accepts this element):
<PLAINTEXT>, though this
tag permitted non-SGML compliant contents that might parse like tags but are merely
text to be displayed as is.<PLAINTEXT> is rapidly falling into disuse and a DTD generated
during this period shows it as depreciated.<PLAINTEXT> is still listed as depreciated, but still part
of the language.<PLAINTEXT> is still listed as depreciated, but still part
of the language. Up through this point <PLAINTEXT> is miscoded as a
unary tag; it was intended that there would be no </PLAINTEXT> tag
at all, but unfortunately this effectively deprived <PLAINTEXT> of
content.<FORM>, <INPUT>,
<TEXTAREA>, <SELECT>, and
<OPTION>. <PLAINTEXT> and now
</PLAINTEXT> as well are permitted by this version of HTML.<PLAINTEXT>, along with such constructs as nesting a header
(<H*> element) within a link (<A> element).<PLAINTEXT> and
its closing tag are also permitted by this version of HTML.<PLAINTEXT>
and also forbids such constructs as nesting a header (<H*> element)
within a link (<A> element), or having a forms
<INPUT> element which is not within a block level element such as
<P>.<PLAINTEXT> continues as depreciated in
the loose form of this HTML (There is no direct way to parse Strict HTML 3.2).<PLAINTEXT> has finally
vanished altogether, never to be heard from again.What one does not find (except buried deep in the details of the HTML DTD's up
through 3.2) is how <PLAINTEXT> differs from <XMP>.
From what places I have found <PLAINTEXT> discussed in various
other introductions to HTML, one would think that all it does to differ from
<XMP> is fail to have a closing tag, or else serve as an alternate
that lets you show a closing </XMP> tag without using character
entities for the "<" and ">"
characters, which character entities wouldn't be properly interpreted within either of
these elements but merely displayed as is. I have even seen <PLAINTEXT>
described and illustrated as though it were an inline element, which it most certainly
is not.
Some of the ways <PLAINTEXT> has been described on the net can
be rather humorous, e. g. "<PLAINTEXT> is the unstoppable
monster of HTML. ... Whereas <XMP> ignores formatting from its own
start to its own end, <PLAINTEXT> ignores all formatting for the
rest of the document, displaying all text exactly as is. It cannot be stopped, it
cannot be turned off. <PLAINTEXT> is deprecated because it messes
up the balance of the document tags...," or "This is the anathema of all
elements. It TURNS OFF html processing in the browser! That's why there's no ending
element - the browser wouldn't recognize it anyway! ... There's just no reason anyone
out there should think of using this tag. Unless you're feeling plain ornery."
One can see that <PLAINTEXT> does seem quite mysterious and even
weird as tags go. Almost everyone simply says "use <PRE> instead,"
or in one case, even that </HTML> has taken its place. It is quite
different from the seemingly related (and similarly depreciated) element,
<XMP> and only correspondingly all the more different from the
<PRE> tag. Starting with HTML 2, the closing tag was introduced
merely to fix a bug that caused <PLAINTEXT> content (the text coming
after <PLAINTEXT>) to be rejected by a parser or validating engine.
As an unintended but inescapable result the closing </PLAINTEXT> tag
becomes optionally permissible (from a valid HTML standpoint), but even if used here it
differs from <XMP> and <LISTING> since those have
always required both opening and closing tags. But actually there is another more
interesting difference.
<PLAINTEXT> is actually a higher-order element than those other
depreciated elements, that is to say that not only is it not an inline element (such as
<CODE>), but neither is it a block level tag (such as
<PRE>), which latter examples would only be permitted within the
<BODY> of the document. <PLAINTEXT> is actually
on the HTML hierarchical level equal to the <HEAD>,
<BODY>, and <FRAMESET> elements. That is to say
that the <BODY> of the <HTML> document must close
with the </BODY> element, either present or implied, before the
<PLAINTEXT> element can come, and then of course everything
thereafter is not to be parsed by the user agent, clear to the end of the file. This
was also meant to be an optimization for the user agent which is free to stop parsing
from that point on and merely reproduce the text that follows it. One sees this from
the line contained in the HTML DTD's which reads:
<!ENTITY % html.content "HEAD, BODY, PLAINTEXT?">
This shows the basic document structure to consist of a HEAD, a BODY, and (optionally,
as indicated by the question mark at the end) a PLAINTEXT. So properly, one must close
out the BODY (but not the HTML) and then comes the PLAINTEXT portion. As the closing
</PLAINTEXT> and </HTML> element tags are optional
they typically would not be included, though I have included them on this file. You may
see the results of that structure here in that some user agents show these closing
</PLAINTEXT> and </HTML> element tags at end of
this file while others may not. (It would be worth your while to do a View of the Page
Source with your browser to see how this page and the pages it calls operate.) Both
of these closing tags are optional so that one would have only the intended text showing
at the end of the document. But within the syntax of HTML it is permissible for them to
be present as they are in this file. However, once one hits the closing
</PLAINTEXT> element tag, none of the usual HTML content is
considered correct and valid except for white space, comments, and the closing
</HTML> tag. The following example would not be permissible, even
though a user agent might simply display everything after the <PLAINTEXT>
element tag without complaint:
... <HR> </BODY> <PLAINTEXT> >I have been following ... (Beginning lines of intended text) . . . (Concluding lines of intended text) ... ecially in the biological sciences. Even fewer fundamentalists. [snip] </PLAINTEXT> <P>Some other text here.</P> <!-- No, that is wrong! --> </HTML> <P>Anything here.</P> <!-- Just as that is also wrong -->
So all of this actually provides some insight into at least one of the reasons that
the closing </HTML> element tag is regarded as optional in all
versions of HTML (XHTML has changed all that of course). It's a carryover from this
particular circumstance where you particularly would not want it, even though it is
syntactically acceptable. The bottom portion of this file is
extracted from a page on my own site where I actually use the
<PLAINTEXT> element, however for this demonstration file I have
added the closing tags to show how they would work, as an example. Incidentally, that
file extract also included a gratuitous use of the <XMP> element
within its <BODY> which is also carried forth here.
<PLAINTEXT> was always meant to put the remainder of the file
into a raw text display mode, no matter what else is encountered. As with
<PRE>, <XMP>, and <LISTING>,
it should be shown in a monospace font (normal size for <PRE> and
<XMP>) with no conversion of any tags or entities, clear to the end
of the file. It would be an acceptible alternative if a closing
</PLAINTEXT> tag causes itself and everything after it to become
invisible, treated like a comment, such that you will not see the closing tag nor anything
after it displayed, but I can think of no good reason to justify introducing any new
code into the browser software programming merely to do this. In addition, a closing
</HTML> tag, if absolutly the last thing in the file, could be masked
out (not shown) even if there is no closing </PLAINTEXT> tag. It is
however expressly inappropriate (though commonly seen) for a closing
</PLAINTEXT> tag to return to a continuation of the HTML body,
similar to </XMP>.
I have created a small cluster of demonstration files to show the various upgrades
and downgrades possible as replacements for the <PLAINTEXT> element
as contained in this demonstration file, showing a list of
alternatives to using <PLAINTEXT>.
Possible downgrades are:
<PLAINTEXT>
is one of the original HTML tags, the only more primitive alternative available is to
provide a file of entirely raw ascii text, as many PLAINTEXT files were originally
converted from. To go back to this, one eliminates all HTML tags and entities
and types out the text exactly as wanted (the original "what you see is what you
get" editing), and then the filename is given a .txt extension instead of the
.htm or .html extensions, or if generating with a script, use the line
Content-type: text/plain instead of Content-type: text/html
within the HTTP header, that is, prior to the two carriage returns that precede the
actual HTML or other file data. In the ascii text file, large and dramatic headings
sort of like the nice HTML headers but cruder (ideally at least five by five characters
wide and tall) can easily be made manually in simple text. In a strange way, this
could also be viewed as a kind of upgrade as well as a downgrade since, unlike
<PLAINTEXT> whose days are numbered, it being a depreciated standard
in the older forms of HTML and altogether eliminated in HTML version 4 onward and all
versions of XHTML, the ability to send simple raw text files isn't going away anytime
soon. If the goal is to optimize user agent parser processing, then this would be the
way to go. But of course one loses all HTML functionality.Possible upgrades are:
<FRAMESET> and a small HTML file with the required elements in the
top window and then putting the plain preformatted text (without fancy headers, as seen
here) as a simple raw text file filling the bottom window.
This would also have the added advantage of keeping the header and other like information
on the screen no matter how one scrolls within the text file. On the downside, this
requires the ability to support frames, which are not popular and not supported on the
older user agents or specialized accessibility user agents. (As you try this sample,
bear in mind that if the user agent display is too small to show an adequate window for
the text file, the boundary should be able to be clicked and dragged upward.) Looking
at the source for this with a View Page Source, note how the preformatted version
(another of these upgrades) of the demonstration file ("plaind5.html") is used
as the fallback in the event one's user agent does not support frames (within the
<NOFRAMES> area). Note also how the external link from the HTML
portion within the upper frame uses the TARGET attribute to make sure that
if the link is followed it will replace the whole frame structure using a parameter of
"_top" (in the upper portion file).<IFRAME> element is both introduced and at the same time
depreciated in HTML 4 (and so carried into XHTML 1.0), present only in the transitional
versions of these DTDs. <IFRAME> reaches back to older user agents,
but <OBJECT> takes over in the strict versions of HTML 4 and XHTML
1.0, and alone continues into further versions of XHTML. <IFRAME>
and <OBJECT> can be combined, using the transitional DTD's as seen
here.<XMP> element or the <PRE> element. The
<XMP> element has the one advantage of being most exactly like the
<PLAINTEXT> element is supposed to be, in that its handling of the
text, its formatting and appearance, is exactly as in the raw text of the file. And
as an extra added bonus, existing user agents implement <XMP> more
consistently even than <PLAINTEXT>. On the downside,
<XMP> is on the same hit list for obsolescence as
<PLAINTEXT>, being depreciated in HTML versions 2 & 3 and
eliminated in version 4 onward and all versions of XHTML. The <PRE>
element gives the same effect, and has the marked advantage of not being depreciated
nor obsolete (it is the most commonly recommended alternative to
<PLAINTEXT> in all the guides, but as seen here there really is a
lot more to it), but on the downside the preformatted text will have to be carefully
checked, replacing any "&" with "&",
any "<" with "<", any
">" with ">", and any
""" with """. (That last I
recommend instead of """ though
""" is fully as old as "<"
and all the rest because HTML 3.2, for some reason (I think a bug) does not recognize
""" whereas it and every version of HTML and every user
agent from the original experiments in 1989 to current and planned for the foreseeable
future all accept and understand """. Besides,
" is one character shorter than ".)<PLAINTEXT> is never reported to have any attributes. However in
many current browser implementations which have maintained it for backward
compatibility, the style, accessibility, event, and language attributes have been
observed for this element. Furthermore, an "ALIGN" attribute
has been noted for the Opera browser.This file, "plain.html," is HTML 2.0 Level 1
compliant.
The <PLAINTEXT> demonstration file
"plaind1.html" is HTML 2.0 Level 1
compliant.
The <FRAMESET> demonstration file
"plainf1.html" is HTML 4.01 Frameset
compliant.
The <FRAMES> Upper portion demonstration file
"plainf2.html" is HTML 4.01 Transitional
compliant.
The <IFRAME> demonstration file
"plaind2.html" is HTML 4.01 Transitional
compliant.
The <OBJECT> demonstration file
"plaind3.html" is HTML 4.01 Strict
compliant.
The <OBJECT> and <IFRAME> combined
demonstration file
"plaind6.html" is HTML 4.01 Transitional
compliant.
The <XMP> demonstration file
"plaind4.html" is HTML 2.0 Level 1
compliant.
The <PRE> demonstration file
"plaind5.html" is HTML 2.0 Strict Level 1
compliant.
The <PLAINTEXT> upgraded pre-HTML text file demonstration file "rfc1111.html" is HTML (original public DTD)
compliant.
The Raw Text demonstration file "plaind1.txt"
and the Frames Lower portion demonstration file
"plaind2.txt" are ascii text, as was the pre-HTML RFC 1111 text file, so HTML validation
does not apply to them.
In the heat of discussion on an email list some months ago, this exchange occurred between myself and another member who was at least familiar with some of the details regarding why an old earth is claimed, and yet he is still clearly disposed to reject all of "Evolution" or Darwin's theory about it. I have seen fit to publish this exchange on the web for the simple reason that nowhere else have I ever found such a clear and even faith-affirming account of what Darwin's theory of natural Evolution is really all about and why it is that we Catholics need not be afraid of it. Any personal names of any list members or other nonpublic figures have been taken out and a few spelling and other typographical errors fixed, but this exchange is otherwise conveyed here precisely as it occurred.
In this email exchange, the usual customs have been followed regarding the manner of indicating which statements are mine and which are those of my correspondent (to whom I am responding):
Read and enjoy:
Show the Original Next Level Up