WorldWideWeb: A Link Was Something You Could Follow

An organization can have all the information it needs and still be unable to answer a simple question. The answer is in a report. The report refers to a program. The program’s author has moved to another institution, and the instructions for finding the report explain how to use a computer you don’t normally use.

There is no shortage of information. There is a shortage of usable connections.

This was the problem behind Tim Berners-Lee’s work at CERN. His March 1989 proposal described a changing research organization whose documents and relationships didn’t fit neatly into one hierarchy. A useful system needed to preserve connections between people, software, equipment, and ideas as those things changed.¹

By the end of 1990, Berners-Lee had a browser and a server running at CERN. The browser was called WorldWideWeb, written as one word. It was also an editor. The space with which we usually write “World Wide Web” helps distinguish the information system from this particular application. Later, the program was renamed Nexus.²³

The first browser’s most consequential operation was modest: select a reference and receive the document it names. That small agreement between author, browser, and server made it possible to connect information without collecting everything into one enormous application.

A working system, after a proposal

The dates matter because several different beginnings get compressed into “the web was invented.” The initial information-management proposal dates to March 1989. Berners-Lee and Robert Cailliau produced a more detailed management proposal dated November 12, 1990. A working browser and server followed during 1990. Public distribution and wider announcement belong to 1991.⁴²

These are stages of a project, with different consequences. A proposal establishes an intention. A working implementation demonstrates that the pieces can cooperate. Wider distribution lets people build something beyond the original installation.

The November proposal describes a common interface to information already stored in different systems. Its example of finding a person’s name in a software description and then finding that person’s email address is wonderfully ordinary. A networked research laboratory could perform extraordinary calculations while making an everyday lookup surprisingly laborious.⁴

Cailliau helped develop and promote the project. Nicola Pellow wrote the subsequent line-mode browser, which widened access beyond the NeXT platform. That contribution mattered because a system described as universal couldn’t remain dependent on owning a particular workstation.²

Berners-Lee built WorldWideWeb in Objective-C on NeXT, adding hypertext to existing text-editing machinery. His account credits those development tools with speeding the work.³

I find this detail more useful than the image of an inventor starting with a completely blank machine. Good development tools can change which experiment is feasible. The available foundation left more time for the part that needed proving.

Tim Berners-Lee at the launch of the World Wide Web Foundation, September 14, 2008. Later photograph by Scott Henrichsen for the John S. and James L. Knight Foundation, source, CC BY 2.0. No alterations.

Three agreements behind a click

A document link needs an address. The browser needs a way to ask for the addressed document. The returned content needs a representation the browser can understand.

Those jobs correspond to addressing, the Hypertext Transfer Protocol, and Hypertext Markup Language. Keeping them conceptually separate is useful. An address tells the browser where and how to look. A transfer protocol moves the requested information. Markup identifies features within the document, including links and headings.

The early addressing documentation describes a scheme, a host, a path, and an optional anchor identifier. A reference can also be relative to the document containing it. The early HTML description gives an anchor an HREF for a link destination and a NAME for a target within a document.⁵⁶

These arrangements allow a short piece of visible text to refer to a much longer address. The reader can select “calibration notes” without typing or understanding the complete destination. The author has recorded the connection once so that readers can use it repeatedly.

That is an important shift in responsibility. A printed citation gives a reader enough information to begin a separate search. A working hyperlink gives the browser enough information to attempt the next step. The attempt may fail, but it is now part of the system.

It also changes how documents can be organized. The information may remain on a remote machine under another group’s control. A link doesn’t require copying it into the author’s own collection. One document can therefore connect several sources without becoming their central repository.

Follow one link carefully

Here is an invented teaching example using syntax documented in early web materials preserved from 1991–92. It explains the mechanism; it doesn’t pretend to be a recovered CERN page or a byte-for-byte reconstruction of the December 1990 browser.

Suppose the current document is:

http://lab.example/notes/index.html

It contains this link:

<A HREF="detector.html#calibration">Calibration notes</A>

The reference has two relevant parts. detector.html names another document in the current directory. #calibration names a location within that document. The early relative-naming rules remove the final component of the current document’s path and append the relative reference.⁷

The resulting address is:

http://lab.example/notes/detector.html#calibration

The browser needs the document from /notes/detector.html. The fragment identifies where to go after obtaining it. An early named target could look like this:

<A NAME="calibration">Detector calibration</A>

The initial HTTP implementation was remarkably small. Its 1991 description, now identified as HTTP 0.9, specifies a request line beginning with GET, followed by the document address, with a carriage-return/line-feed termination. The server returns the document stream and closes the connection to mark its end.⁸

Our example request would therefore begin:

GET /notes/detector.html

This is an explanation of the simple early protocol. A modern HTTP request ordinarily contains additional machinery, including a version and headers, so it should not be mistaken for contemporary client instructions.

Original explanatory diagram, 2026. Invented addresses and early-web syntax documented in 1991–92; not a historical screen or an exact reconstruction of the 1990 application.

Notice what the link has saved. It carries a destination rather than a copy of the destination’s contents. A later edit to the target document can become visible the next time a reader retrieves it. That benefit comes with a dependency: the address must continue to lead somewhere useful.

If the target author changes the anchor name, the document may still load while the precise location becomes harder to find. If the file moves and its old address stops working, the reference can fail altogether. Neither possibility invalidates linking. Both make address maintenance part of publishing.

Relative links introduce another useful tradeoff. A collection of documents can move together while preserving relationships within the collection. An absolute address is valuable when naming a resource elsewhere. A relative address is economical when describing a neighbor. The surrounding document supplies part of its meaning.

The reader could also be the author

The creator’s account of the later, 1993 screen describes marking a target and linking selected source text to it. That editor workflow shows a relationship being recorded without manually typing its markup.³

That workflow makes an instructive distinction. The author chooses a relationship between two pieces of information. The application records the address needed to express it. The representation is still there, but the person can work through selection and navigation.

Editing was limited to local files; HTTP PUT wasn’t implemented.³ Composition and publication to a remote server were therefore different operations.

That limit matters. Calling the first browser an editor does not establish that every remote page was writable by its reader. Access to information and authority to alter the stored original are separate decisions. The interface could make composition convenient without granting permission to rewrite someone else’s document.

The account’s screenshot dates to 1993: its color and inline pictures differ from the original grayscale application, which opened pictures in separate windows.³ A later image needs a later date.

A narrow beginning could travel

The NeXT application demonstrated a rich interface, but its platform limited its potential audience. Pellow’s line-mode browser approached the same information from a simpler display environment. CERN’s history records distribution to colleagues in March 1991 and an Internet newsgroup announcement in August.²

This broadened the project’s practical meaning. A shared information system didn’t require every reader to have the same screen or controls. A graphical application and a text-oriented client could both follow links. The common agreement concerned documents and destinations; presentation could vary.

The early system also concentrated on a manageable subset of the problem. The November proposal explicitly deferred elaborate multimedia and sophisticated network authorization. Reading its ambitions as a specification for today’s web would obscure the choices that made a prototype achievable.⁴

There were costs. A link could become stale. A server could disappear. The browser couldn’t guarantee that an author’s statement was correct merely because it knew how to retrieve it. A connected document collection still depended on people maintaining and explaining it.

Those limitations are useful historical evidence. The first web was a working arrangement for distributed information, not a promise that information management had become effortless.

The connection was the invention worth keeping

WorldWideWeb helped turn an information-management proposal into something a person could operate. A reader could follow an address-bearing reference. An author could create those references within an editable document. A server could answer requests without taking responsibility for the entire network.

The arrangement allowed growth through additional documents, servers, and clients. Each new participant could add a useful piece without acquiring every other participant’s software or information. That is a more interesting kind of simplicity than merely having a short request line.

It is tempting to judge the first browser by comparing its display with a contemporary website. The more revealing comparison concerns the work before and after the click. Finding related information had involved remembering where it lived and how to reach it. The link put enough of that knowledge into the document for a machine to attempt the journey.

The browser didn’t make the report accurate or the laboratory organized. It made a recorded connection usable. Organizations were still free to lose information, but they now had a rather better way to find it again.

Footnotes

1. Tim Berners-Lee, “Information Management: A Proposal”, March 1989, preserved with historical provenance notes. ↩

2. CERN, “A short history of the Web”, chronology of 1990 implementation, Nicola Pellow’s client, and 1991 distribution. ↩ ↩² ↩³ ↩⁴

3. Berners-Lee, “The WorldWideWeb browser”, creator’s account distinguishing the original application from a 1993 screenshot. ↩ ↩² ↩³ ↩⁴ ↩⁵

4. Berners-Lee and Robert Cailliau, “WorldWideWeb: Proposal for a HyperText Project”, November 12, 1990. A proposal states intended capabilities; it is not proof that all were implemented immediately. ↩ ↩² ↩³

5. Early W3 naming schemes, preserved November 1992 snapshot. ↩

6. Early HTML tags, preserved November 1992 snapshot, anchor attributes and document structure. ↩

7. Early relative-naming rules, preserved November 1992 snapshot. ↩

8. “The Original HTTP as defined in 1991”, W3C historical protocol description. ↩