This file illustrates the actual proper use of the <NEXTID>
element, or "tag," as it was used HTML version 2. As illustrated and used
here, this is its final and most mature form, and the only form which can be validated
using any public IETF and W3C DTD today. This element served to enable the NeXT web
designing tool to generate automatic NAME labels for its anchors. It was generated by
that web editing tool automatically and was not to be adjusted or entered by hand.
This element has the distinction of being the first element to become one of the "Lost
Tags" by being eliminated from the official public DTD's of the HTML versions.
It is also probably one of the least understood of all of the early HTML elements,
being poorly documented, not explained in any depth anywhere, and those who obviously
understood how it worked couldn't be bothered to explain it to the rest of us.
The HTML 2 specification does not mention this element as having been depreciated,
so some may think it had more standing than the other tags which were depreciated
early on, namely the <PLAINTEXT>, <XMP>, and
<LISTING> elements. Those other three were listed from the
almost the earliest surviving DTD's onward as being at least depreciated, and as being
outright obsolete and eliminated in HTML 4 onward along with all versions of XHTML.
But <NEXTID>, if one studies the HTML 2 DTD carefully (or
experiments with the W3C Validator), also gets deleted in the strict versions of HTML
2 right along with <PLAINTEXT>, <XMP>, and
<LISTING>, and in HTML Version 3.2 it is quietly eliminated
altogether, unlike those other three which continue as "depreciated" elements
in HTML 3.2.
Therefore, with Version 2 of the of HTML specification, the <NEXTID>
tag (along with the <PLAINTEXT> and <XMP> and <LISTING> tags) was for all intents and purposes,
also depreciated. Notice how HTML 2 survives now in four basic varieties which can be
validated, and which may or may not accept this tag, depending upon the version:
<NEXTID> in a non-SGML compliant
form that simply used the numeric value alone as an "attribute."<NEXTID> to take
only a number for a value of its newly-introduced attribute N.<NEXTID> is the same as it would take in HTML 2,
finally allowing the use of a name instead of only a number for its attribute value.<NEXTID> <NEXTID> can be individually
deslected for display with a simple SGML command.<FORM>, <INPUT>,
<TEXTAREA>, <SELECT>, and
<OPTION><H*> element) within a link (<A> element)<H*> element)
within a link (<A> element), or having a forms <INPUT>
element which is not within a block level element such as <P><NEXTID> has vanished altogether,
never to be heard from again.Since this element was exclusively generated by the NeXT web editor, its functionality was limited, and with the arrival of new web editing tools the need to carve out this room in the specification for this tag faded into the background. In the early 1990's, the NeXT web browser and editor was easily the best and most sophisticated web technology available, very much ahead of its time. All of those other primitive browsers invented back then, such as the original line-mode or Libwww browsers and suchlike were but attempts to provide some web functionality to run on the much more primitive vt100-compatible Unix terminals as found throughout most of the rest of the internet.
Back in those heady days where the web was little more than an idea in the mind of Tim Berners-Lee, then employed at the CERN Laboratory in Switzerland, the internet had on it perhaps a few hundred computers, all mainframes, such as IBM's and Digital VAX's, scattered all around the world. They were located usually in academic settings, as well as scientific research departments and corporate research divisions. In those days, people exchanged e-mail, logged on to various remote computers on the internet with Telnet, and transferred files (mostly scientific research papers, all written in carefully formatted ascii text) using FTP. A few small computers, such as the original Xerox 8010 Star released briefly in 1981, and the IBM PC as they were advancing by that time, could use a sort of graphics user interface, but these were viewed more or less as toys, with no direct connection to the internet, or at most capable of only a "dumb terminal"-like connection to one of the mainframes on the internet.
The NeXT computer (a surprisingly small black cube which is still kept on display
in a museum today) was then easily the most advanced display computer anywhere on
the internet. It may have been in or shortly after 1994 that Tim Berners-Lee finally
abandoned his NeXT computer in favor of other platforms, as the rest of the world was
finally beginning to catch up with NeXT, and they also came a lot cheaper. So the
real question is, how did the NeXT web editor use the <NEXTID>
element?
Despite an exteme paucity of information, I have been able to glean out something
of a consensus of what it actually did with this element. As I give this explanation,
please bear in mind that I make a few minor assumptions which I will list as
questions at the end of this article. If there are any actual users of NeXT left out
there with functioning NeXT computers or collectors willing to pull their old relic
out of the moth balls and actually fire it up, I would be most happy and appreciative
for whatever clarifying details they can supply or corrections they can make to my
presentation of it here. As any such information comes in, I most certainly will
incorporate the results of it into future revisions of this page. One thing which
has been especially helpful has been the discovery of a late file in which
<NEXTID> is used in its final and most mature form (the file was
actually prepared using the NeXT editor in March 1994): RFC822: Standard for ARPA Internet Text
Messages. This file originally existed as pure ASCII text but was given a
"Partial Hypertext conversion by Tim Berners-Lee/CERN." It represents
the last and most developed form that the <NEXTID> tag usage took
before falling into disuse. My example here is modeled on that.
NeXT had the ability to generate automatically its own "names" for anchor
tags. From looking at that file, it appears that these anchor names were created
whenever a interdocument linking between a Table of Contents and the rest of the
document was created. One can do much the same thing today with Microsoft Word, but
the result in the file is not so human-readable. When this feature was used, both
the source and destination of the link would be given NAME attributes
with these machine-created anchor names. That the destination would have such a name
to serve the purpose of giving the link some place in the document to go to when
selected is obvious, but unexpectedly the NeXT editor also places such names on the
source of the link (along with the HREF attribute). Perhaps the latter
was thought to make it easier to find one's way back from the destination to the
Table of Contents listing. These machine-created names would take on the form of a
letter followed by a number, and with the creation of each new anchor name, the
number would be advanced by one so that each would be unique. Perhaps the letter used
was hard-coded to be a "z" since I have found no examples (other
than hand-entered ones) with any other letter.
Say for example the user enters four section headings into the Table of Contents
(and presumably also writing paragraph material within the sections). The heading
for each of the four sections would be assigned NAME values of
"z0", "z1", "z2", and
"z3". The first of these would produce an entry in the Table of
Contents like this: <A NAME="z0" HREF="#z4">FIRST SECTION
NAME</A> and the section header at the section itself would be marked
like this: <H2><A NAME="z4">FIRST SECTION
NAME</A></H2>. This continues for the next three sections, named
z5, z6, and z7 (and Table of Contents entries
named z1, z2, and z3), and each are
automatically given anchors with these names. Then he decides to save and close his
document. NeXT would then add within the header of the HTML document a special tag,
<NEXTID N="z8"> to inform itself of where to continue
its naming convention from, the next time it opens the document.
So, imagine the web author opens the document for further editing. He wants to
add a couple new sections after his second section and append four more sections at
the end. So he opens the document, and the NeXT editor finds and reads this
<NEXTID N="z8"> tag and knows to give the first of
these new sections he adds the name of z8 in the Table of Contents and
z14 at its content body. What he now has, once he is done again and
closes the document might look like this:
<HTML> <HEAD> <TITLE> ... whatever ... </TITLE> <LINK, META, BASE, etc. as applicable for the head of this document> <NEXTID N="z20"> </HEAD> <BODY> <A NAME="z0" HREF="#z4">FIRST SECTION HEADING</A> <A NAME="z1" HREF="#z5">SECOND SECTION HEADING</A> <A NAME="z8" HREF="#z14">NEWLY INSERTED THIRD SECTION HEADING</A> <A NAME="z9" HREF="#z15">NEWLY INSERTED FOURTH SECTION HEADING</A> <A NAME="z2" HREF="#z6">ORIGINAL THIRD (NOW FIFTH) SECTION HEADING</A> <A NAME="z3" HREF="#z7">ORIGINAL FOURTH (NOW SIXTH) SECTION HEADING</A> <A NAME="z10" HREF="#z16">SEVENTH SECTION HEADING</A> <A NAME="z11" HREF="#z17">EIGHTH SECTION HEADING</A> <A NAME="z12" HREF="#z18">NINTH SECTION HEADING</A> <A NAME="z13" HREF="#z19">TENTH SECTION HEADING</A> <H2><A NAME="z4">FIRST SECTION HEADING</A></H1><P> ... whatever ... </P> <H2><A NAME="z5">SECOND SECTION HEADING</A></H1><P> ... whatever ... </P> <H2><A NAME="z14">NEWLY INSERTED THIRD SECTION HEADING</A></H1><P> ... whatever ... </P> <H2><A NAME="z15">NEWLY INSERTED FOURTH SECTION HEADING</A></H1><P> ... whatever ... </P> <H2><A NAME="z6">ORIGINAL THIRD (NOW FIFTH) SECTION HEADING</A></H1><P> ... whatever ... </P> <H2><A NAME="z7">ORIGINAL FOURTH (NOW SIXTH) SECTION HEADING</A></H1><P> ... whatever ... </P> <H2><A NAME="z16">SEVENTH SECTION HEADING</A></H1><P> ... whatever ... </P> <H2><A NAME="z17">EIGHTH SECTION HEADING</A></H1><P> ... whatever ... </P> <H2><A NAME="z18">NINTH SECTION HEADING</A></H1><P> ... whatever ... </P> <H2><A NAME="z19">TENTH SECTION HEADING</A></H1><P> ... whatever ... </P> </BODY> </HTML>
Then he sends a copy of this document to his friend who also has a NeXT editor,
and who deletes sections z7 and z19 and adds ten more,
z20 through z29, and then deletes paragraphs z24
and z29. So then the NEXTID value is z30 when he
returns it modified, to the original author, looking thus:
<HTML> <HEAD> <TITLE> ... whatever ... </TITLE> <LINK, META, BASE, etc. as applicable for the head of this document> <NEXTID N="z30"> </HEAD> <BODY> <A NAME="z0" HREF="#z4">FIRST SECTION HEADING</A> <A NAME="z1" HREF="#z5">SECOND SECTION HEADING</A> <A NAME="z8" HREF="#z14">NEWLY INSERTED THIRD SECTION HEADING</A> <A NAME="z9" HREF="#z15">NEWLY INSERTED FOURTH SECTION HEADING</A> <A NAME="z2" HREF="#z6">ORIGINAL THIRD (NOW FIFTH) SECTION HEADING</A> <A NAME="z10" HREF="#z16">SEVENTH (NOW SIXTH) SECTION HEADING</A> <A NAME="z11" HREF="#z17">EIGHTH (NOW SEVENTH) SECTION HEADING</A> <A NAME="z12" HREF="#z18">NINTH (NOW EIGHTH) SECTION HEADING</A> <A NAME="z20" HREF="#z25">NEW NINTH SECTION HEADING</A> <A NAME="z21" HREF="#z26">NEW TENTH SECTION HEADING</A> <A NAME="z22" HREF="#z27">NEW ELEVENTH SECTION HEADING</A> <A NAME="e23" HREF="#z28">NEW TWELFTH SECTION HEADING</A> <H2><A NAME="z4">FIRST SECTION HEADING</A></H1><P> ... whatever ... </P> <H2><A NAME="z5">SECOND SECTION HEADING</A></H1><P> ... whatever ... </P> <H2><A NAME="z14">NEWLY INSERTED THIRD SECTION HEADING</A></H1><P> ... whatever ... </P> <H2><A NAME="z15">NEWLY INSERTED FOURTH SECTION HEADING</A></H1><P> ... whatever ... </P> <H2><A NAME="z6">ORIGINAL THIRD (NOW FIFTH) SECTION HEADING</A></H1><P> ... whatever ... </P> <H2><A NAME="z16">SEVENTH (NOW SIXTH) SECTION HEADING</A></H1><P> ... whatever ... </P> <H2><A NAME="z17">EIGHTH (NOW SEVENTH) SECTION HEADING</A></H1><P> ... whatever ... </P> <H2><A NAME="z18">NINTH (NOW EIGHTH) SECTION HEADING</A></H1><P> ... whatever ... </P> <H2><A NAME="z25">NEW NINTH SECTION HEADING</A></H1><P> ... whatever ... </P> <H2><A NAME="z26">NEW TENTH SECTION HEADING</A></H1><P> ... whatever ... </P> <H2><A NAME="z27">NEW ELENENTH SECTION HEADING</A></H1><P> ... whatever ... </P> <H2><A NAME="z28">NEW TWELFTH SECTION HEADING</A></H1><P> ... whatever ... </P> </BODY> </HTML>
It should be obvious why it wouldn't do for the editor to maintain some database of the paragraph NEXTID values. Now one other question would be, why not simply go through the file on opening it and find the next available number, or even prepare a list of all the numbers skipped (due to deletions) and reuse them? The philosophy is obvious: better a dead link than a false one. Sure, it is a sad day for the child when he goes to his favorite Care Bear or Teletubby site and finds only "Error 404 - File Not Found," but how much worse to find his site replaced with some pornographic site! Academic integrity is similarly an issue, as one might want to link to some passage in another's research article online, only to have the link now go to some place else where the footnoted quote is not found at all. Plus, at least during an editing session, who is to say that the deleted section might not be reinserted at some point, thus reactivating the link?
So the natural solution makes quite some sense - put the number with the file so
as to know what number to pick up the numbering scheme from, and by burying it in an
HTML tag where it won't show, and in fact the author need not be conscious of it at
all. Nevertheless, I have included such NAME assignments on each of
the paragraphs and headings in this file, along with the appropriate
<NEXTID> tag, consistent with how I described, as can be seen by
performing a View of the Page Source. In this file and also the sample shown above,
I have also avoided one other cosmetic detail which one can see in the genuine
<NEXTID>-holding file, namely that for each <A>
tag, the tag invariably gets a new line for the NAME attribute, so a
typical entry would look like:
<H2><A NAME="z33">4.6. REFERENCE FIELDS</A></H2>
instead of the more expected:
<H2><A NAME="z33">4.6. REFERENCE FIELDS</A></H2>
Perhaps this also aids the NeXT editor in finding the link markers, since every
NAME marker is always the first thing on a new line. So
<NEXTID> is quite limited to being an automated indexing system for
the NeXT editor alone. This element has no other discernable effects. But it did
provide a good and worthy example of what sort of information (besides document
<TITLE>) should go inside the <HEAD> of a document.
The other <HEAD> type tags all came later, starting with
<ISINDEX> soon after, <LINK> by the time of the
earliest surviving usable DTD (January 1993), <BASE> in HTML 1,
and <META> in HTML 2.
So what assumptions have I made, and what questions do I have?
NAME
label is generated when a Table of Contents line is linked to a section header in the
body of the text. Might some other occasions also cause the generation of such links
by the NeXT editor? And are they always generated (and deleted) in pairs in that
final and most mature form of <NEXTID> as generated by NeXT?<NEXTID> that I have found in my
researches have been consistent with this operating model. One reference has it that
this may have served as some mechanism for chaining from one document to another, sort
of like some early primitive <LINK REL=NEXT ... >
tag, and another reference may indicate that it was used by the Apache server software
in connection with its process forking. While I rather discount these theories, might
not some proprietary application have so used <NEXTID>?As this element has no discernable effects in the display of a web page in a browser
it would seem that the only "implementation" for this would be to ignore it as
indeed all modern browsers do. However, a Web editing tool might be able to use it, and
if so it should use it in a manner consistent with how the NeXT Editor used it. Such an
editing tool should correctly pick up where a NeXT-edited file left off, regardless of
the form it takes from oldest to the final, or even enable NeXT to pick up where this
editor left off. If one wants to store some other different data in the file to be
picked up next time it is edited by the same editing software, it is best that some
other proprietory tag would be used. <NEXTID> is properly meant to
track automatically generated <A> NAME values, not anything else.
Though the nature of the use of this element has not significantly changed since its
introduction, at least two variations of its functioning have been observed in some
older files. What I used in this file is per the HTML 2 standard, but a standard current
at the start of 1993 specifically precludes the use of a letter in the attribute value,
such that an example would look like <NEXTID N="55">, as can
be seen in this old
file. It would appear that NAME labels were then being generated for
all <A> tags, except where named by the author, even if nothing
pointed to them at all. An even more primitive use is seen in this older file
in which there are no quotes around the parameter and the atribute value itself is all
that it has, i. e. <NEXTID 62>. This earlier application is consistent
with the description last updated November 1992, and unlike the later applications, does not
put the NAME attribute starting on a new line the way the later versions do.
There are in fact a great many <NEXTID> bearing files in the W3C
archive (which contains all the very oldest HTML files on the entire internet) since this
was formerly a much more important tag, especially when virtually all HTML development was
taking place on the NeXT editor.
This element has no further upgrades or downgrades. One can find however, other
proprietary elements in which some HTML editor inserts something into HTML by software
with no apparent user effect) in, for example, the "phantom" NATURALSIZEFLAG
attribute to the <IMG> tag added by certain older versions of the Adobe
software, and there are unspecific reports of some other similarly inserted elements. All
of such are proprietary extensions; only <NEXTID> ever found its way
into an official W3C/IETF HTML document standard.
All these labels do enable one to jump to any section header within a document. All
contents entries at the start of this article lead to the header named sections. I have
included here links to those NAME values referenced in this document but
not pointed to by any of the contents above. Notice how a couple of them don't go
anywhere as they represent a deleted paragraph, or else (in one case) the
<NEXTID> tag's value itself:
z0
z1
z2
z3
z4
z5
z6
z7
z9
z16
z17
z18
z20
z21
z24
z26
z28
This file, "nextid.html," is HTML 2.0 Level 1
compliant.
The RFC 822 file is not HTML 2.0
compliant,
but due only to an extra </A> tag at the end.
Next Level Up