Through most of 1992 and into the beginnings of 1993 there was a considerable amount of speculation as to how the web was to advance from that version as seen since January of 1991. During this time even the key architects of HTML were tossing out ideas of various sorts of elements, attributes, as well as looking into trying to find a way to define the HTML "language" in terms of a parsing model, which soon settled on using an SGML base. Most of the tags described here saw absolutely no deployment into the World Wide Web, though as one will see, some few did serve as prototypes of later elements and attributes that would emerge, and some few may one day emerge more or less as given here. The tags described here are mentioned in the various files cited and shown in the future HTML directions file. Such discussions and speculations even continued well into 1993 and 1994 with some further suggestions and proposals being mentioned in the second release of HTML 1 (what I here call "HTML 1.m"). After HTML2.0 these sorts of proposals and discussions and proposed elements and attributes would be gathered up into the versions of HTML+ and then finally with the draft of HTML 3.0.
The only "Lost tag" introduced during this phase that actually came to
be deployed to any extent is the <HEADER> tag, which is exactly
replaced with its lasting successor <HEAD> in all future
versions. This could almost border on the level of a proprietary tag, since it
seems to have belonged to the NeXT editor alone, but since it is the earliest, and
since so many W3C archive files from this period bear this unusual tag, I have
included it in my successive listings, something not done for any of the other tags
described herein. This <HEADER> element and <HPn>
are the only conventionally mentioned elements I have listed whose disappearence was
so long ago that they show up on no surviving DTD. These tags therefore have the
distinction of being the very first truly Lost Tags. Though <OL>
disappeared earlier, its subsequent return, complete with even the same form fit and
function, removes it from the category of Lost Tags.
This is the only other experimental tag from this period to actually find use in
any files, though in this case it is only a tiny handful of files, all generated by
Dan Connolly shortly after its permanent replacement element <PRE>
already began to come into use. And that is exactly what <TYPEWRITER>
is, merely an early and experimental version of <PRE>.
In the earliest surviving draft of a DTD for HTML, it appears that before calling
the main contents of an HTML file the <BODY>, they wanted to call
it <DOCUMENT> instead. And they had not as yet bothered to name
the <HEAD> of the document, specifically. This tag appears only
in that draft DTD of HTML (which I have chosen to call "HTML 0.f") and which
is to be found demonstrated in its fullness here.
Carl Barker (another CERN member) was looking for some new features in the HTML
protocol, and one idea of his mentioned was the ability to put an HTML header on
some other non-HTML file data. In a sense, <PLAINTEXT> already
did this with the ability to put straight ASCII text after it, but with a new
NOTATION attribute of <BODY> one might be able to
put other non-HTML things after the <BODY> tag. The following is
found in that file: <BODY NOTATION=postscript>. So one
could imagine a postscript file with an HTML header. Or picture the same used for
including the old UNIX troff commands (this would have made it easy to move old
UNIX manuals to HTML), by means of something like this:
<HTML> <HEAD> <TITLE<Thank-you Note</TITLE> </HEAD> <BODY NOTATION="troff"> .nf .ll 4.0i .in 2.0i 101 Main Street Morristown, NJ 07960 15 March, 1997 .sp 1i .in 0 Dear Sir, .fi .ti 0.25i I just wanted to drop you a note to thank you for spending the time to give me a tour of your facilities. I found the experience both educational and enjoyable. I hope that we can work together to produce a product we can sell. </BODY> </HTML>
Although having to do that for the whole body seems a bit excessive, it might have
been a potentially useful thing for small portions of a document, say a
<DIV> or <SPAN> section or suchlike.
One could easily see what use something like a <KEYWORDS> tag
might have for containing search keywords for a page. Perhaps it would have looked
like this:
<KEYWORDS>HTML DATE DOCUMENT Tag Element Attribute WWW</KEYWORDS>
Something of this very sort finally did emerge with HTML 2.0 in the form of the following:
<META NAME="KEYWORDS" CONTENT="HTML DATE DOCUMENT Tag Element Attribute WWW">
As has occured however, too many web pages were abusing this sort of field by raising their importance by such things as repeating a term many times, etc. so search engines by and large have abandoned reference to this field. A pity.
This was intended to provide a way to date the document, and also to specify when its
information is expected to be out of date (so that memory caches can be cleared or stored
files known to be obsolete). Like the <KEYWORDS> tag, this one came
to be replaced with a <META>. As described at the time, there was no
clear standard for how the date would be specified, so the example given reads as:
<DATE CREATED="920630123067" EXPIRES="920706000000">
but with more contemporary dating schemes it would have looked like this:
<DATE CREATED="Tue, 30 Jun 1992 02:57:13 GMT" EXPIRES="Mon, 06 Jul 2008 00:00:00 GMT">
Something of this very sort finally did emerge with HTML 2.0 in the form of the following:
<META HTTP-EQUIV="created" CONTENT="Tue, 30 Jun 1992 02:57:13 GMT"> <META HTTP-EQUIV="expires" CONTENT="Mon, 06 Jul 2008 00:00:00 GMT">
Tim Berners-Lee (and others) have long wanted to introduce some sort of <SECTION>
element which would enable portions of the document to stand somewhat on their own as
separated from other portions of the document. This was to be something sort of like what
<DIV> does, with the one exception that it would affect the header
values (<H1> through <H6>) by effectively increasing
the number by one for each level of nesting within <SECTION> tags. So
for example, if you had a <SECTION> within a <SECTION>
and within that an <H2> element, it should be rendered like an
<H4> element. Alternatively, one may simply use a plain
<H> tag and let its value be set by the level of nesting within
<SECTION> tags it comes within. Reports of these ideas have varied
and in one place one sees a <SUBSECTION> which is probably a mistake
meant to refer to a <SECTION> nested within another such
<SECTION>, and in the same place a <HEADING> tag
meant to refer to what was otherwise simply to be called <H>.
Unlike others elements of this experimental category, <SECTION>
and <H> are finally emerging in XHTML 2.0 as actual and valid elements,
and with the intent and purposes discussed here. One might illustrate its use thus
(slightly adapted from the 1992 presentation):
<HTML><HEAD>
<TITLE>foo</TITLE>
</HEAD><BODY>
<SECTION>
<H> Level 1 Header </H>
<P>paragraph associated with above header</P>
<SECTION>
<H> Level 2 header </H>
<P>paragraph associated with above header</P>
</SECTION>
</SECTION>
</BODY></HTML>
The final version of HTML+ from April 1994 attempted a similar thing using a
"<DIVn>" (where "n" would be anything from 1
through 6, coinciding with the 1 through 6 of the header elements).
Tim Berners-Lee preferred to call the attribute of <NEXTID>
"N" while Dan Connolly and others called it
"ID." One sees this in the oldest DTD from August 1992 as a list
of the tags and attributes from June 1992, and extending clear to the descriptions
for future directions for HTML written November 1992. But by the first usable DTD
in January 1993, "ID" had finally been changed to be
"N" and "ID" is no longer seen. The need
was simply to give the <NEXTID> value an attribute name so as to
make it valid SGML. Before the introduction of either attribute name, the attribute
present in the tag was merely the number itself.
Though nothing is said anywhere of any "content-type"
attribute for <A>, Dan Connolly used this unknown attribute for
<A> several times as an indicator of the MIME type for the file
referenced (pointed to). By mistake in one place he used an attribute name of
"TYPE," accidently anticipating the actual use that
TYPE would come to have when reintroduced in HTML 4.01 (and 4.0),
instead of the actual current intended use for TYPE which was for some
relational information and which now goes as REL. The various HTML
future directions files even anticipated the "REL" attribute
by name in one place (before changing it to TYPE), and also the
COMPACT attribute, which is seen (in a flawed form) in the August 1992
DTD.
Before the <HPn> tags could really catch on Tim Berners-Lee and
Dan Connolly were already discussing what sort of highlighting tag elements should exist in
future versions of HTML. Dan Connolly preferred the Tex logical highlighting (e. g.
<EM>, <TT>, and <CITE>), all
of which soon became a part of the language. A similar idea also considered would
be the O'Reilly/Hal DocBook tag elements, such as <Emphasis>,
<OopsChar>, <wordasword>,
<CiteBook>, <Subscript>, and
<Superscript>. These alternatives were not used in favor of the
TeX tags, though similar tags now exist, such as <SUB> and
<SUP>. As something separate from these they were also discussing
what they then called "physical tags" such as <Bold>, and
<italic>, etc. that would finally emerge as the far simpler and
more economical <B> and <I>. Of the DocBook
tags listed here, <Emphasis>, <CiteBook>,
<Subscript>, and <Superscript> rather obviously
now exist in HTML as <EM>, <CITE>,
<SUB>, and <SUP>, respectively.
<OopsChar>, and <wordasword> are DocBook tags
with no equivalents in HTML and none planned. One was used for escaping the SGML
DTD for DocBook for some span and the other for specifying a non-technical usage of
a technical term (could effect searches, but would have no special appearence).
One other tag hinted at, but most likely a mistake, and not seen discussed in any
of the HTML future directions files, was a <HEADERS> element.
This is seen in the oldest surviving usable DTD when listing the elements suitable
for the <BODY> of a document, where the following occurs:
<!ENTITY % bodyelement
"P | %heading |
%list | DL | HEADERS | ADDRESS | PRE | BLOCKQUOTE
| %literal">
One can see here besides the usual DL, ADDRESS,
PRE, BLOCKQUOTE, P, and %heading
(H1 through H6) , %list (UL and
etc.), and %literal (XMP and etc.), there is listed there
a mysterious HEADERS element. As no further description is made of any
supposed <HEADERS> element, it seems that this was merely a
typographical error, perhaps redundant to the %heading entry in this
list. In the first release of HTML 1 ("HTML 1.k" in my descriptions) this
mistake was carried forth utterly unchanged. The second release of HTML 1
("HTML 1.m" in my descriptions) purged this error and <HEADERS>
was never seen again. Even with the DTD's that have it, it is impossible to create
a document with this element that parses validly. It does no harm, has no effects,
but is (by all evidences) an error.
The HTML documentation for what I call "HTML 1.m" lists the
<EXPIRES> and <META> elements, not as current
but as being (one) proposed and (the other) obsolete. In particular it mentions
<META> as being "obsolete" even though this element is not
seen in any previous version of HTML, and <EXPIRES> as being
"proposed," though there is little justification for it. This seems to be a
mistake. Unless there be some undocumented and unevidenced version of HTML between
the first and second releases of HTML 1 (apart from the first release of HTML+ which
includes neither of these elements), <META> can not possibly have
been done away with. And again it is a far more general and useful tag than the
<KEYWORDS>, <DATE>, and <EXPIRES>
proposed tags it would replace when finally introduced in HTML 2.0. Had
<EXPIRES> ever existed as a real element, it is unclear whether it
would have appeared as:
<EXPIRES>Mon, 06 Jul 2008 00:00:00 GMT</EXPIRES>
or (assuming an attribute name of "DATE"):
<EXPIRES DATE="Mon, 06 Jul 2008 00:00:00 GMT">
Interestingly, one could actually reflect this ambiguity in SGML by defining this element thus:
<!ELEMENT EXPIRES - O CDATA>
<!ATTLIST EXPIRES DATE CDATA #CONREF
-- document expiration date
-->
The HTML 1.m description mentions that some browsers were beginning to implement
a <COMMENT> element for material which is to be commented out and
not displayed or put to any other use in displaying or formatting a page. This is
redundant to the SGML mechanism for comments which was already in place for nearly
all user agents, certainly all that were SGML-based. The element is implemented
in some modern browsers such as Windows Explorer, but not in certain others. The
HTML 1.m documentation describes this element as obsolete, due to the SGML commenting
structure meant to become universal.
HTML 1.m includes forms exactly as they would come to exist in HTML 2.0 level 2,
but a couple additional attributes were being proposed at this time (and these
attributes were already being incorporated into HTML+). The document for HTML 1.m
lists both for <INPUT> (along with CHECKED although
that last is peacefully incorporated into the DTD), DISABLED as being
proposed for <OPTION>, and ERROR as being proposed
for <SELECT>. The DISABLED attribute would soon
appear in HTML 4.01 (and 4.0) on <INPUT>, <OPTION>,
<SELECT>, and <TEXTAREA>, and also on the new
forms controls <BUTTON> and <OPTGROUP>. This
would cause a field to display in a grayed out format that indicates that it cannot
be selected (perhaps to show what might have been selectible had other options been
previously chosen) and prevent user entry in the specified fields or groups of fields.
The other proposed forms control attribute ERROR was intended to put the
user agent on notice that whatever initial choice given as a default was erroneous
and as such must be changed before the form can be submitted. It would have been up
to the user agent to display this by some sort of means (italic text, different color,
help window that pops up like a TITLE help when the cursor is placed
over the field, or even only an error message of some sort that pops up only if one
tries to submit the form). A similar thing can be done, for example on the typical
forms radio button fields by an initial condition of no fields checked, or more than
one since exactly one alone is valid. However, the downside to this is that it only
forces the user to modify the contents, not to provide contents with any crude
semblance of correctness, which is something that the scripting languages would soon
come to do with far greater alacrity. Hence, in this case the ERROR
attribute was never incorporated and need not ever be.
One proposed forms element was the <HTEXTAREA> tag which would
work much like <TEXTAREA> but instead of invoking a simple
"Notepad"-like text editor it would instead invoke some sort of "What
You See Is What You Get" HTML editor, something sort of like an editable
<IFRAME> window object allowing the user to design a small part
of a web page without having to bother with the HTML, all as part of entering a
form. This does not seem to have ever been implemented since it would depend upon
either incorporating such an editor into any browser, or else finding a way to
invoke whatever such editor (if any) a user should happen to have on his system.
The HTML future directions files also use a number of clearly fictional tags,
produced merely for demonstrational purposes and not intended to exist as any actual
tags (and they don't). A "<start>" tag is used to
demonstrate what happens when something that looks like a tag in included in the
literal text data within an <XMP> element. A closing tag of
"</foo" is used to test if it would close out an
<XMP> element, and another to test what would happen if a
closing tag took an attribute ("</foo junk>"). An
"<unknown>" tag is used to test what would happen if an
unfamiliar tag is encountered (the tag should be ignored and not shown, but any content
of the tag should be shown as normal text). Finally there is a demonstration to test
what would happen if a tag with an impossibly long name is encountered, so there is a
"<gggggreeeeeeeeeeeeeeeeaaatbiglongnameofatagthatsreallyjustjunk>"
tag included in one of the more degenerate test case files.
Except for <SECTION> and <H> which rightly
belong to XHTML 2.0, and those various elements and attributes as are presently incorporated
into contemporary HTML (e. g. the LaTeX elements <EM> and the like,
the <META> element, and the DISABLED attribute) there is
no reason to implement any of these purely experimental and nonexistent tags/elements or
attributes. Since the <COMMENT> element is implemented in certain
kinds of user agents and not implemented in others, that should continue as they are
today, since one of the few uses of it is to distinguish between them, for example:
<COMMENT>If you can read this you are obviously not using Windows Explorer.</COMMENT>
It would be permissible, to accomodate what few files are known to use a few of
these, to implement <HEADER> to be as <HEAD>,
<A content-type="<<something>>"> to be as
<A TYPE="<<something>>">,
<NEXTID ID="<<something>>">
to be as <NEXTID N="<<something>>"> (should
a NEXTID value be of use at all), and <TYPEWRITER> to be as
<PRE>, but I severely doubt this would ever happen as there is far
too little justification for it. <UNKNOWN> should be a "reserved
word" as far as element names go, such that for all time no element shall ever
be named "UNKNOWN" in order that this may always be used for testing user
agents (e. g. browsers) and parsing agents (e. g. HTML validators) to see what they
will do when encountering an unfamiliar tag.
This file, "alook.html," is HTML 2.0 Strict Level 1 compliant.
Next Level Up