After the rapid disappearence (or failure to exist in the first place) of the text
formatting tags <HP0> through <HP3>, the first
element or attribute that even faintly could seem to be a formatting or style sort of
attribute instead of a document structure is the WIDTH attribute of the
<PRE> element. But the goal of HTML had been from the beginning that
it would focus exclusively on document structure and not get into how a document is to
be presented. That was originally to be left up to the browser or other user agent, or
perhaps there may have been some vague idea of style files a browser might use, or at
least some intended presentation styles meant for the various document structure
elements.
In the beginning, only <A> (and also its ancillary tag
<NEXTID>) had anything within the "<" and ">"
brackets except for the element name itself. This attribute makes its first known
appearance in the working draft of a DTD by John Connally in January of 1993 (tracked
in this HTML history as "HTML 0.h"). But if WIDTH is to be understood
as a presentation or formatting attribute, then it does have its predecessor in that even
before <PRE> had been been introduced, the user had a choice of either
<XMP> or <LISTING> which differed from each other
only in the width of the presentation font to be displayed on the terminal screen. But
notice that there were two separate elements of that kind with which to make the
distinction. With the introduction of <PRE> (and even as discussed
in a previous <TYPEWRITER> form), it was intended that one element
would serve both formats (and possibly some others).
This gives WIDTH the distinction of being the first of many formatting
attributes to be subsequently added to many of the various tags, something which would
come in full flower most especially in HTML 3. But at this level, it was reasonable and
justified and fully understandible. WIDTH had significance in precisely one
sort of place, and that was with crude line-mode type browsers, the kind that could show
on simple DOS or VT100 type computer screens. Some of those screens, the VT100-compatible
ones at least anyway, had the capability to provide their display in a normal or narrow
format. The conversion was screen-wide as it actually changed the mechanical scanning
of the electron gun in the CRT, causing it to take longer to draw a single scan line,
thus giving more time to show more letters. The result made the letters narrower (but
not shorter, so this is not about simply using a smaller font), but instead of having
room for only 80 across the width of the screen, now it could have room for 132. That
size in turn came from the standard width of fanfold computer paper and the line printers
that printed on it, and they had room for 132 characters across the width of the paper,
plus room for the sprocket holes on each side to advance the paper through the printer.
The idea had been that sometimes a person might want to view what is to be printed (or could be) on a screen instead of using up all that paper, and that required a screen monitor with a width of 132 characters. But they are so much easier to read when you make them wider, such that there is only room for 80 across the screen's width that normally you would not go for the capacity to display all 132 characters most of the time.
This gets down to one of the interesting features of the raw text tags. In nearly all else of HTML, the text spacing is dictated by the sizes of the letters (as given in their particular font chosen, for example "w" is wider than "i" in most fonts (it is only the same in what is called "monospace" fonts), and it is up to the browser to decide where the line breaks need to be to fill up the screen and not run over a line's width. This would come in handy for various sized displays, be it from custom sized computer screens or from expandible display windows. The browser could take its text material and adapt it easily and painlessly. Likewise if the font is to be increased in size through a user setting on the browser, that too would allow the line breaks to fall where they best serve to fill the page without overflowing.
But the one real limitation with such an approach is when you want the characters
to follow some specific formatting that cannot be mapped to conventional HTML document
structuring commands. Images, tables, applets, IFRAME documents, and objects
in general were all in the future. 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 <PRE> to enable extracts of the same to be inserted into an
HTML document intact. <PRE> went beyond the others in providing
the ability for mild typeface commands and links, so now you could get such things as
you could with <XMP> but now with enhancements, namely that the Band
name "Devo" and authors "Kernighan and Ritchie" and "RFC822: Standard
for ARPA Internet Text Messages" can be cited and the word "major"
emphasised in the tabular information example resulting in italics for them,
the A, B, and C of the diagram can be bolded, and the chapter titles in the table
of contents of RFC822 can be activated as links:
ASCII ART:
_-_
[o,o]
\-/
(I think this guy is a member of Devo)
DIAGRAMS:
^ ^
/ \ / \
/ X \
/ / \ \
/ / \ \
< A < C > B >
\ \ / /
\ \ / /
\ X /
\ / \ /
V V
(The intersection of A and B is C)
TABULAR INFORMATION:
Rainfall: Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
1984: 23 22 18 12 6 7 2 0 1 16 8 24
1895: 21 20 6 8 7 5 1 1 1 9 16 22
1986: 20 10 8 4 2 0 0 0 0 6 9 12
(Looks like we are heading into a major drought here)
COMPUTER PROGRAMS:
main() /* Fahrenheit-Celsius table */
{
int fahr;
for (fahr = 0; fahr <= 300; fahr = fahr + 20)
printf("%4d %6.1f\n", fahr, (5.0/9.0)*(fahr-32));
}
(Anyone but me remember Kernighan and Ritchie?)
TABLE OF CONTENTS:
PREFACE .................................................... ii
1. INTRODUCTION ........................................... 1
1.1. Scope ............................................ 1
1.2. Communication Framework .......................... 2
2. NOTATIONAL CONVENTIONS ................................. 3
(Extracted from RFC822: Standard for ARPA Internet Text Messages)
The downside of all this of course is what to do if the text is too wide for
the display. Early terminal screens did not come with scrollbars across the bottom to
shift the material right to left to see its full width on a less than wide enough screen,
so where HTML's clever text formatting served so well in adapting to a small screen (or
even to a large one, without a lot of empty space across the side of the screen), such
a section of strictly formatted and spaced characters is simply what it is, and it fits
or it doesn't. Introducing a different and separate <LISTING> tag
and subsequently providing a WIDTH attribute to <PRE>
which can be set to "132" to make <PRE> fit on the screen
just like <LISTING> was a fully understandible and justified
extension to add to HTML. But it proved to be an unfortunate precedent.
As it was in its own brief day however, <PRE WIDTH=132> was
purely meant for such primitive computer display screens. It never functioned on NeXT,
nor any version of Mosaic, nor any other more contemporary type browser. The irony of it
is that it could have been easily enough implemented, for example the way Microsoft Explorer
and many other contemporary browsers in fact implement the <LISTING> tag,
namely by using a smaller font. Such a more contemporary adaptation is not fully comparible
to the original functioning of this early font width setting, since changing the font size
also changes the height of the letters, but it would be better than nothing. At least it
might have enabled a wide raw text format to not fill the full width of the screen, and
therefore not to force the reader to shift it back and forth with the bottom scrollbar.
But for some reason, no browser other than some few of those earliest line mode
primitive terminal browsers ever implemented the WIDTH attribute of
<PRE> (even those which correctly used a smaller font for
<LISTING>). This is so even though WIDTH remained in
the official HTML language clear through XHTML 1.0 Transitional. The following versions
of HTML include this attribute for <PRE>:
<PRE> would
be the name of the new monospace HTML element (instead of <TYPEWRITER>)
and so included it as part of the language, but also added this WIDTH
attribute to it.<PRE> attribute WIDTH continues as part of
the language.<PRE> attribute WIDTH continues as part of
the language.<H*> element)
within a link (<A> element), or having a forms <INPUT>
element which is not within a block level element such as <P><FORM>, <INPUT>,
<TEXTAREA>, <SELECT>, and
<OPTION>, leaving only <ISINDEX>.<H*> element) within a link (<A> element)<FONT>, <MAP>, <APPLET>,
and <TABLE><ISINDEX>, are included only as
"deprecated" tags. WIDTH is also depreciated in this version.<isindex />. The width attribute of
<pre> also continues only as a depreciated tag.The intended values for this attribute were supposed to be "80" (the
default), and "132" (making <PRE WIDTH="132">
similar to <LISTING> as far as using a narrow-sized font goes). In
addition, one also might have implemented double width characters (as they were on the
VT100 and many other primitive terminals), resulting in "40" (half of 80, the
default) and "66" (half of 132). Those four values comprise all the possible
valid values this attribute was ever meant to accept.
Ideally, a browser should (if they want to backward-compatible implement this
attribute), scale the width of the monospace font (similar to how the height and
width of an image can be independantly scaled in HTML 3) while retaining the same
height. Failing that, it would be enough that WIDTH="132" would
set the <PRE> to the next smaller font size,
WIDTH="66" to set it to the next larger font size, and
WIDTH="40" to set it to two sizes larger font size.
Try here to see if your browser supports any of these:
(This uses <PRE WIDTH="132">)
_-_
[o,o]
\-/
(This uses <PRE WIDTH="66">)
_-_
[o,o]
\-/
(This uses <PRE WIDTH="40">)
_-_
[o,o]
\-/
In virually all browsers (and all modern ones) these will all look the same as:
(This uses <PRE WIDTH="80">, the same as using <PRE>)
_-_
[o,o]
\-/
For greatest forward and backward compatibility, the WIDTH attribute
should ideally govern only the width of the text characters, perhaps by taking the
font character pixel descriptions and scaling the width but not the height, in a manner
similar to how the WIDTH attribute can adjust the width of a displayed
image. Failing that, the font size should be scaled accordingly, on a continuous
scale, or failing even that, the nearest font size to a correctly scaled font should
be used. In all cases, the scaling factor should be computed by the formula of
80 / WIDTH, such that a WIDTH value of 80 results
in the normal default size (the width and/or size the characters would be in the context
of the document if WIDTH is not specified), a value of 132 would result in
a narrower (or smaller) font about 60% the size, such that 132 of them would fill the
same line width as 80 characters with a WIDTH value of 80. It is acceptible
if the WIDTH parameter value is used differently if a "%"
or other punctuation or letters accompany the numeric value, e. g.
<PRE WIDTH="85%">
If there are size and/or width setting style sheets also present on an instance of a
<PRE> tag, priority should be given to the style sheet if a
<!DOCTYPE> specifying HTML 4.0, 4.01, 5, or any form of XHTML is
recognized, but to the width (or resulting font size) specified by this attribute if not.
One thing not recommended (but commonly seen) is for <LISTING> to
be implemented as though it were actually <PRE WIDTH="132">
instead of as a narrow-font <XMP> as it should be and always was
intended to be. Using <LISTING> would therefore be a quick a dirty
way to simulate <PRE WIDTH="132"> quite accurately for
most modern browsers.
Possible downgrades are:
<XMP> and <LISTING> choice
- The only previous alternative to the <PRE> WIDTH attribute
was the choice of using <XMP> or <LISTING>, both of which
are older tags than <PRE>. For some unknown reason, most modern browsers
actually implement <LISTING> as though it were
<PRE WIDTH="132"> in that entities are resolved and HTML tags
have their effects displayed instead of their raw text displayed as it should be.Possible upgrades are:
WIDTH
- The proper way to set font sizes using the stylesheet commands.This file, "prewid.html," is HTML 2.0 Level 1
compliant.
The WIDTH Approximation Stylesheet demonstration
file "prewid1.html" is HTML 4.01 Strict
compliant.
Next Level Up