This file illustrates the actual proper use of the <XMP> and
<LISTING> elements, or "tags," as they were used in the
original conception for HTML, and clear through version 3.2. These elements
served to enable the web designer to show the text in the file exactly as typed, as
otherwise HTML automatically eliminates all the white space, reducing it down to a
single space if even that, and lets the line breaks fall where appropriate given the
screen and font size. This was also useful for printing such things as tabular data
and ascii art, because of using a monospace font as opposed to the more variable
width fonts used for HTML which are generally more presentable as simple reading
text, but would fail to line up correctly the way a monospace font would do. One
must also recall that in the earlier days of developing HTML, most writers and
preparers of text documents on computers were long accustomed to using tabs and
spacing to distribute characters on the screen as needed to portray their point
visually.
In these earliest HTML days, if you wanted to draw something or format a table,
there was only one way, and that needed tags for monospace letters which also respect
the amount of white space (instead of collapsing all white space into a single space
for display or a new line where needed, as is done all elsewhere in HTML). This was
the one area where the old raw ASCII text documents were still advantageous, and HTML
could only catch up by providing <XMP>, <LISTING>,
and (somewhat later) the more advanced, useful, and SGML-compliant <PRE>
tag, to enable extracts of the same to be inserted into an HTML document intact. So
now you could get such things as:
It's companion tag <LISTING> was similarly introduced
to portray wider outputs, particularly those which might be printed on the old
132-column-wide computer fanfold paper, for example:
From the 1991-1992 era of HTML there are many surviving examples of
<XMP> being used in the W3C archives (For example:
A,
B,
C,
D,
E,
F,
G,
H,
and I),
and I have found one <LISTING> example
here. The
oldest surviving instance of both of these tags, albeit only as demonstrations however, is found
here.
With HTML versions from the oldest surviving DTD to 1 through 3 of the of
HTML specification, the <XMP> and <LISTING>
elements (along with the <PLAINTEXT>
element) were 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,
these non-SGML-compliant tags, but of HTML 3.2, only the non-strict version
can be validated:
<XMP> and shortly
after, <LISTING>, though these tags permitted non-SGML compliant
contents that might parse like tags but are merely text to be displayed as is.<XMP> and <LISTING> are rapidly falling
into disuse and a DTD (HTML "0.h") generated during this period shows them as
depreciated.<XMP> and <LISTING> are still
listed as depreciated, but still part of the language.<XMP> and <LISTING> are still
listed as depreciated, but still part of the language.<FORM>, <INPUT>,
<TEXTAREA>, <SELECT>, and
<OPTION>. <XMP> and <LISTING>
are permitted by this version of HTML.<XMP> and <LISTING>, along with such
constructs as nesting a header (<H*> element) within a link
(<A> element).<XMP> and
<LISTING> are also permitted by this version of HTML.<XMP> and
<LISTING> 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>.<XMP> and <LISTING>
both continue as depreciated in the loose form of this HTML (There is no public document
type declaration for Strict HTML 3.2).<XMP> and <LISTING>
have finally vanished altogether, never to be heard from again.Typically (and with reasonably good cause), the web designer is advised against
using these depreciated/obsolete tags in favor of <PRE>. What is
not often made clear is how <PRE> differs from
<XMP> and <LISTING>. Perhaps it is obvious that
<LISTING> is meant to use a narrower font than <XMP>
and <PRE>, but a more fundamental difference is seldom explained
plainly for the novice, let alone is he told why there was such a push to eliminate
these older tags. Superficially, <XMP> looks exactly like
<PRE>, as for example the famous Irish toast, actually using here
<XMP>:
In most browsers it looks no different using <PRE>:
St. Patrick was a gentleman Who through strategy and stealth Drove all the snakes from Ireland, Here's a toasting to his health; But not too many toastings Lest you lose yourself and then Forget the good St. Patrick And see all those snakes again.
However, it is not merely a matter of eliminating a redundant tag, as there is a
difference. Lets try the same thing, but with a little bit of emphasis, using the
<B> Bold font tag, and also replacing "and" with "&".
First, here is this poem using <PRE>:
St. Patrick was a gentleman Who through strategy & stealth Drove all the snakes from Ireland, Here's a toasting to his health; But not too many toastings Lest you lose yourself & then Forget the good St. Patrick & see all those snakes again.
And now see what the same code would give you if you used <XMP>
(but this here can only simulate it with <PRE> for reasons I will
get to):
St. <B>Pat</B>rick was a <B>gent</B>leman Who through <B>strat</B>egy & <B>stealth</B> Drove <B>all</B> the snakes from <B>Ir</B>eland, Here's a <B>toast</B>ing to his <B>health</B>; But <B>not</B> too many <B>toast</B>ings Lest you <B>lose</B> yourself & <B>then</B> For<B>get</B> the good St. <B>Pat</B>rick & see <B>all</B> those snakes a<B>gain</B>.
It can get messy when you have any of the "magic" characters (e. g.
"<" or "&") in your file and wish to see them correctly, in
converting from the sort of text that looks fine using <XMP> to
text that looks the same using <PRE>, you must make all the
suitable substitutions throughout the passage. If these characters appear (for
example in HTML samples), it will not look good. If within <XMP>
you had (again I use <PRE> to simulate <XMP>
for the same reasons I will get to):
The <STRONG> tag (ending with </STRONG>) is more emphatic than the <EM> tag (which ends with </EM>). Use the & character entity to place an ampersand in the text.
Then merely replacing the <XMP> with <PRE>
element, what you get is:
The tag (ending with ) is more emphatic than the tag (which ends with ). Use the & character entity to place an ampersand in the text.
And so to fix it you would have to change it to look like (here I can and do use
<XMP> to show easily what the raw HTML looks like):
And that will fix the <PRE> version, arriving where you
started, but now using <PRE> instead of
<XMP>:
The <STRONG> tag (ending with </STRONG>) is more emphatic than the <EM> tag (which ends with </EM>). Use the & character entity to place an ampersand in the text.
Since, as seen in the examples above, the <XMP> element really
is different from the <PRE> element, why eliminate it? This gets
down to the nature of the structure of HTML. HTML's rules are actually derived from
SGML rules. Where the rules have been followed there is absolutely no chance of
any misunderstanding, and as the web is potentially read by all around the world,
this is a serious and valid concern. For just as in poetry, the English language
can be all turned around and still come out understandable (e. g. "Away went the
boy, to the barbershop he went"), there are more normal standards that are
normally meant to be used, lest one be misunderstood. ("The boy went away to
the barbershop." - not as sonorous, but no chance of any misunderstanding.)
Likewise, most user agents (browsers) can be astonishingly forgiving of the most
horrid grammatical mistakes in HTML and still generate a pleasing presentation of
the information so encoded, but for fear of misunderstanding (what looks great on
one user agent can look like crap on another), there are again much more standard
forms for the language's "grammar" to be followed.
In particular, there is no way within the scope of SGML and its parsing program
to "turn off" this parsing for some stretch of text within a document
purporting itself to be HTML. This means that the stretches of material contained
between the <XMP> tags, or between the <LISTING>
tags, or coming at all after the <PLAINTEXT> tag, though it is
only copied like text to the user agent's screen, nevertheless continues to be
parsed and checked. In all the places in this file where I have actually used
<XMP> and <LISTING>, I have been judiciously
careful to see to it that what is contained between these tags will still parse out
harmlessly, no matter how goofy some will look as examples of what can happen when
these preformatted tags are not used correctly. Imagine what would happen if one
had between the <XMP> and </XMP> tags within
a document (and again I am using <PRE> and </PRE>
here as in the two places above to substitute for <XMP>, so I
don't really have this in my source) the following:
... and then there comes the </BODY> tag & the </HTML> tag which close out the document.
The parser, scanning this section, would encounter the </BODY>
element closing tag, and having seen it, wonder what all that other stuff is in the
file that comes after it. By the definition of HTML the only things which can come
after the </BODY> tag are white space, comments, the
</HTML> closing tag, or (where rarely applicable)
<PLAINTEXT>. Then again it would do the same for the
</HTML> element closing tag. And nothing (but empty
white space and equally unimportant comments) comes after </HTML>.
Finally, one could also get an error from having the & character not followed by
any of the valid character entities (such as "<"), and
this too could be judged an error.
It gets worse even than that. It ignores opening tags, merely noting their
presence but not evaluating them, but closing tags (since it is watching carefully
for the </XMP> tag) all get noted, but won't get matched up to
an opening tag even if present. In short, trying to validate a file containing a
lot of <XMP> or <LISTING> or
<PLAINTEXT> text can be a real mess. But <PRE>
on the other hand eliminates these problems, having real tags only where the web
designer wants them (as for example with the <B> element in the
poem above, or links, or italics), and the rest are mere text and harmless character
entities from the standpoint of the parser. Notice how even in this demonstration
file, three of the samples which should have been done with <XMP>
had to be simulated using <PRE> just to keep this file actually
in compliance to the standard. See here to view an
SGML Failure Mode demonstration file using the actual <XMP> and
other tags for the examples simulated above, and to see more of why these tags are
just not good SGML. Then see what happens when you try to
validate
such a file with such monstrous constructions.
<LISTING> is meant to be just like <XMP>
except of course for its narrower font size. In fact, it is supposed to be capable
of fitting 132 characters within the same screen width as <XMP>
fits 80 characters. This is a carryover from some of the most ancient line-mode user
agents which ran on vt100-compatible terminals. Per the vt100 standard, it normally
displays up to 80 characters across its screen width, but with a special "escape
sequence" (called such because it begins with the <ESC> key
code, as is entered using that key on the terminal keyboard) that puts it in a
special 132 column display format. This way, if the text material is wider than 80
columns (up to 132), it will all display correctly.
Otherwise either it wraps around, creating alternate lines on the screen (very
ugly), or else it crops off everything to the right of the 80th column.
One should be able to deduce from this why it is that <XMP>
has its 132 column version (<LISTING>) while
<PLAINTEXT> does not. With <PLAINTEXT> you
don't normally have a closing tag, and so if you had a hypothetical
<PLAINTEXT-132> tag which set the screen to the 132 column wide
mode, it would end up leaving it in that mode. So, where the
<LISTING> opening tag would cause the escape sequence to be sent
which widens the screen, the </LISTING> tag at the end would
cause the opposite escape sequence to be sent so as to ensure that the terminal is
set back to normal when display is concluded.
As it happens in font sizes available today however, it seldom works out to that
exact 80 to 132 ratio. In fact what one may get is simply the next smaller font
size, which might fit a little over 100 characters within the same width as
<XMP> would fit 80. Furthermore, because they are smaller,
they are also shorter, and not merely narrower, where they were only narrower on
the vt100 and compatible display devices.
One other thing to know is that many popular user agents, through a mistake or
bug in their program (and one they certainly won't care enough to fix), actually
treat <LISTING> as though it were a reduced font
<PRE> statement, thus honoring at least some of the elements
and entities found therein as it is not supposed to do, and some don't even bother
reducing the font size or even enlarge it! I enclose here a small test for one to
find out about their own user agent. Each of the following line groups is the
same, except for the fact that the <XMP> one only counts out 80
characters and the <LISTING> one counts out to 132 characters.
First comes the <XMP> version:
And here comes the <LISTING> version:
I have created a small cluster of demonstration files to show the various upgrades
possible as replacements for the <XMP> and
<LISTING> elements contained in this
<LISTING> demonstration file and this
<XMP> demonstration file, showing a list of
alternatives to using these elements.
Possible downgrades are:
Possible upgrades are:
<PRE> for
<XMP> - There really is only one upgrade to
<XMP> and that is to use <PRE> and then go
through and replace 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 """ has been
understood from as early as entities existed (at least as early as 1991). Besides,
" is one character shorter than ".)<PRE> for <LISTING>
using "WIDTH" - This was the original method of creating 132
columns, namely specifying a WIDTH parameter of 132, so that
<PRE WIDTH="132"> would be to <PRE> what
<LISTING> would be to <XMP>. This has the one
advantage of being HTML version 2 compliant, but the disadvantage that few if any
user agents created since the days of vt100-compatibility line browsers ever
implemented it. Acceptable values for the WIDTH attribute of
<PRE> were supposedly 40 (for double-wide characters, which goes
clear back to the vt100 terminal), 80 (the default), and 132, with a remotely possible
66 (double width 132 column mode, also possible on the original vt100). In all
likelihood you will find here that it looks just like a regular <PRE>
block since it is so rarely implemented. Since this is more like a kind of style or
formatting attribute anyway, it is depreciated in HTML 4 and 4.01 Transitional, and in
XHTML 1.0 Transitional, and deleted from the Strict forms of HTML 4, 4.01, and XHTML
1.0, and from all further versions of XHTML. And as with the <XMP>
one must make all of those replacements of certain characters with character entities.<PRE> for <LISTING>
using <FONT> and <BASEFONT> - HTML 3
introduced the <FONT> and <BASEFONT> elements
which can be used with <PRE> to reduce the font size. A reduction
of one font size amounts to the same amount as <LISTING> ought,
which is to say, not as much as necessary, but consistent with typical renderings of
the <LISTING> element. Unfortunately, <LISTING>
is one of the least consistently rendered elements in all of HTML among the various
user agents. As it is, even this one works only in certain current implementations.
Increasingly, more user agents are no longer honoring the <BASEFONT>
element. Note also how it is necessary to use <BASEFONT> to shrink
it, and then use <FONT> everywhere else to compensate, which is a
rather hokey solution. This is because the SGML parser will not accept the
<FONT> element within the <PRE> element. And
that in turn is because <PRE> is meant to be a monospace font with
the characters all lining up. If <FONT> is permitted within the
<PRE> area, one could have differing sizes of fonts throughout the
section and things won't line up, or cannot be made to line up readily or accurately.
However, every user agent capable of understanding <FONT> would
have no problem interpreting the propriety solution of putting the <FONT
SIZE="-1"> tags immediately inside the <PRE>
tags, thus. And as with the <XMP>
one must make all of those replacements of certain characters with character
entities.<PRE> for <LISTING>
using "STYLE" - HTML 4 officially introduced style sheets
with which it is finally possible to make the <PRE> content smaller
without having to resize the whole document nor use a propriety non-validating format.
In my example file the "STYLE" attribute uses a value of 62% to
try to match the same as the original vt100 ratio, but which instead seems to get just
a same single font size reduction as <FONT> and
<BASEFONT> solutions generated. And as with the
<XMP> one must make all of those replacements of certain characters
with character entities.<XMP> and <LISTING> are never reported to have
any attributes. However in many current browser implementations which have maintained
them for backward compatibility, the style, accessibility, event, and language
attributes have been observed for these elements. Furthermore, an
"ALIGN" attribute has been noted for the Opera browser, along with
"HEIGHT" and "WIDTH" for the
<LISTING> element.This file, "listin.html," is HTML 2.0 Level 1
compliant.
The <LISTING> demonstration file
"listind1.html" is HTML 2.0 Level 1
compliant.
The <XMP> demonstration file
"listind2.html" is HTML 2.0 Level 1
compliant.
The <PRE> demonstration file
"listind3.html" is HTML 2.0 Strict Level 1
compliant.
The <PRE WIDTH="132"> demonstration file
"listind4.html" is HTML 2.0 Strict Level 1
compliant.
The <BASEFONT> demonstration file
"listind5.html" is HTML 3.2
compliant.
The <FONT> demonstration file
"listind7.html" is not any kind of HTML
compliant.
The <PRE STYLE="font-size: 62%"> demonstration file
"listind6.html" is HTML 4.01 Strict
compliant.
The SGML Failure Mode demonstration file
"listind8.html" is not any kind of HTML
compliant.
Next Level Up