Working PLAINTEXT Tag Element Example

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):

HTML "0.a" - from the beginning through January 10, 1991
This tag had not been invented as yet, so no examples are found from this period.
HTML "0.c" - from January 23, 1991 though November 23, 1992
This early version of HTML very soon introduced <PLAINTEXT>, though this tag permitted non-SGML compliant contents that might parse like tags but are merely text to be displayed as is.
HTML "0.d" - from November 26, 1992 through May 24, 1993
During this span, <PLAINTEXT> is rapidly falling into disuse and a DTD generated during this period shows it as depreciated.
HTML "1.k" - Version 1 (first release)
In this first published draft of HTML, <PLAINTEXT> is still listed as depreciated, but still part of the language.
HTML "1.m" - Version 1 (second release)
In the next published draft of HTML, <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.
HTML Version 2 Level 1
This is like the level 2 default but it excludes all the forms elements, i. e. <FORM>, <INPUT>, <TEXTAREA>, <SELECT>, and <OPTION>. <PLAINTEXT> and now </PLAINTEXT> as well are permitted by this version of HTML.
HTML Version 2 Strict Level 1
This is like regular Level 1 but it also excludes <PLAINTEXT>, along with such constructs as nesting a header (<H*> element) within a link (<A> element).
HTML Version 2 Level 2
This is the default and includes and permits all HTML Level 2 functions and elements and attributes. <PLAINTEXT> and its closing tag are also permitted by this version of HTML.
HTML Version 2 Strict Level 2
This excludes <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>.
HTML Version 3.2
<PLAINTEXT> continues as depreciated in the loose form of this HTML (There is no direct way to parse Strict HTML 3.2).
HTML Version 4.0 and 4.01
<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>
>I have been following ... (Beginning lines of intended text)
(Concluding lines of intended text)  ... ecially in the
biological sciences.  Even fewer fundamentalists.

<P>Some other text here.</P>  <!-- No, that is wrong! -->
<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.

Recommended Implementation

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

Upgrades and Downgrades

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:

Possible upgrades are:

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.

If I lack tact

- an email exchange regarding Darwinian Evolution and Faith

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):

>Comments of the correspondent to which I am responding are started with >a single ">" character at the start of the line. Comments without any such character are part of my response. >> In a few places, my correspondent has cited some of my words from previous >> emails in this exchange (not reproduced here), indicated by the double ">> "

Read and enjoy:

Show the Original              Next Level Up

>I have been following this debate all along and have refused to put in my >two cents until I read this message. I finally feel that I must respond >with my own thoughts. First, let me state that I do not like what I feel >has been presented as a dichotomy in this debate: that one must either >believe in Darwinian evolution or in creationism. I reject both. The theories of evolution, however flawed they may prove to be, at least represent such an attempt, and our religious tendency to abandon such research to the atheists is Christianity's Great Shame. There were many great scientists who were Catholics way back when, but you don't see many (if indeed any) today, especially in the biological sciences. Even fewer fundamentalists. [snip] </PLAINTEXT> </HTML>