How to cite this paper
What do we still lack?
Or: Prolegomena to any future hypertext system
Symposium on HTML5 and XML: Mending Fences
August 4, 2014
The main contention of this paper is that today's Web infrastructure and practice
do not exist in a vacuum, but in the context of a long and valuable history of literate
systems, and that there are still many ways to benefit from that history right now.
The notion of hypertext includes the phenomena of reference and cross-reference, annotation,
quotation, and multiple co-ordinated views (themselves perhaps a special case of cross-reference).
These have thus been with us for millennia, since nearly the advent of literacy itself.
The advent of printing, then electronic documents, then networking, and finally near-universal
access, have each been important turning points. In some ways, modern document systems
merely take operations that have always been central, and make them faster and more
widely available; and yet the change at each of these turning points has been so great
as to make huge practical differences.
In the course of these changes, it is easy to focus on valuable things that are or
seem new, to the extent of overlooking valuable things that have been lost. Not all
old things are worth keeping; not all new things are worth adding. But a close look
at today's hypertextualized world, especially in the long context of literate systems
that have gone before, reveals many features and capabilities that have gone missing,
despite being no less valuable than they have been before the advent of the Web.
This paper, therefore, begins with a very brief overview of some highlights of the
origins of hypertext, first in pre-computer history, and then in the early days of
computing with text and other media. This overview calls out a variety of capabilities
that have not survived on the Web, or more precisely, survive in specialized applications
and environments, rather than as ubiquitous functionality available to all readers
Working around the lack of such literate features is always possible — we have computers,
after all. But in today's environment it requires having or finding a great deal of
expertise. Even more daunting for the vast majority of users, is figuring out which
technologies to learn, and being often surprised at the sudden need for a whole new
PHP, XInclude, XSLT, JSON, HTTP, Unicode, SVG, MathML, REST, the APIs of social media
companies; the list never really ends. When beginning the journey from "reader" to
"author", a few technologies may promise to suffice; but in the end you never know
how many you will need, often because of edge cases that you would expect are covered,
but are not.
We can do better for users, and we do keep moving forward. But those who ignore the
history of literacy are, as the saying goes, doomed to reimplement it, to do so far
later than need be, and to implement it poorly at first.
Preamble on the peculiarities of hypertext history
Hypertext, being all about connecting pieces of information to each other, has been
around since the advent of literacy (and even before, since a great deal of reference
occurs in speech and even gesture). Even before many computers could handle lower-case
letters (much less non-Latin alphabets), people began using them to create, analyze,
read, search, and even link documents. Yet as Ka-Ping Yee points out,
The World-Wide Web implements some of the ideas of hypertext, but the original hypertext
vision has yet to be completely realized (Yee02). Computer-based hypermedia systems have been with us since the 60s, and imagined
even earlier; the underlying notions go back much further, for many were done, if
slowly, long before automation:
For somewhere he has spoken... (Hebrews 4:4; the
somewhere is Genesis 2:2)
Pliny, Tacitus, and others often referred to other parts of the same work.
Now the rest of the acts of Ahaziah which he did, are they not written in the book
of the chronicles of the kings of Israel? (2 Kings 1:18)
The Talmud is an enormous collection of rabbinic teachings and opinions, and is probably
the most heavily linked and interconnected hypertext ever created (for example, see
the English-language Talmud resources at http://www.halakhah.com).
Concordances (inverted indexes by content words) were produced for works that engendered
the motivation; these served much the same role as search engines. James Strong produced
an exhaustive concordance to the King James Bible translation in 1890 (Str90), and Roberto Busa (Bus80) launched the field of humanities computing in 1946 with his Index Thomisticus, a concordance to the works of Thomas Aquinas (available at http://itreebank.marginalia.it).
Euclid's geometry included fold-out 3-D models of polyhedra (see DeR94, p. 19), which is fair to consider a case of multimedia publishing.
National Geographic occasionally used to include vinyl records, tucked between magazine
The precision of references to documents and places in them has gradually improved
through history. In oral tradition reference was necessarily difficult. In scrolls,
it was common to include a summary when referring back to prior materials, perhaps
because of the very difficulty of access. The change to codices made page numbers
an obvious if imprecise enhancement, and may in itself have contributed to heavier
and more accurate use of cross-references. Pliny's
Natural History (~78 CE) included not only many cross-references, but also a Table of Contents (Sta81), though at the end of the Preface Pliny credits Quintus Valerius Soranus with having
created one earlier.
Even before Gutenberg some parallel texts were produced, facilitating comparative
studies. However, with the printing press cross-reference became more useful, since
many copies of a work shared the exact same pagination (not to mention content). According
to Boardley (Boa14), the book
Sermo in festo praesentationis beatissimae Mariae virginis printed by Arnold Ther Hoernen (Cologne, 1470) is the first extant book to include
printed foliation (leaf-numbering).
Polyglot Bibles provided aligned text in multiple languages, and sometimes multiple
dense streams of footnotes, cross-references, and other annotations (not to mention
illuminations and other artwork). The near-ubiquitous Biblical chapter and verse numbers
originated with Stephen Langton (1150?-1228) and Robert Stephanus (1503-1559), respectively.
Romanello and Pasin (2011) describe the similar process for Classical literature:
Historically, canonical references are the result of an effort — whose origins can
be traced back to the Renaissance (Martin 2003; Berra 2011) — made by the scholarly
community as a whole to provide a precise, stable and shared way to refer to Classical
texts. Since the early stages of Humanities Computing and Digital Humanities (Bolter
1993; Crane 1987; McCarty 2005), canonical references were regarded as the ideal candidate
on which to experiment the potentialities of hypertext: indeed they can be seen as
hyperlinks in potentia pointing [to] a text from within another. More recently (Crane et al. 2009) they
were considered as a discipline-specific kind of named entities that Classics scholars
should be provided with tools to search for within their texts.
How was hypertext possible (before the Web)?
Of course, hypertext as we usually think of it uses computers to take the reader from
location to another without extensive indirection or search. Navigating is a matter of seconds
(or even less), rather than of minutes to months (for example, if the reader had to
travel to Alexandria to find a copy of the referenced work). But this isn't the whole
story, because it is a one-way street. On paper it is hard to support much more, although
hypertext pioneer Andries van Dam famously commented that when in college he always
bought the dirtiest used copies of textbooks he could find: dirtier meant more highlights,
marginalia, and other input from prior readers (van87, Mar98). This perspective of readers contributing to an ongoing dialog with authors, facilitated
by networking, influenced many hypertext researchers.
Computer-based hypertext systems before the Web sought synergy between established
literate practices and the novel dynamic capabilities of computers with ever-growing
storage and speed. The first such systems were developed in the mid-60s: NLS/Augment
and HES/FRESS. All these systems had extensive features automating the same kinds
of connective features known for millennia on paper, as well as making use of the
speed and communication capabilities of computing.
Hypertext involves many things, but perhaps the single most fundamental concept is
that it blurs the distinction of writer and reader. A reader writes in the margin,
becoming an author; perhaps a
sub-Creator in much the sense Tolkien described (Tol47). This much has always been true (though has become more awkward on ebooks and on
the Web). In contrast, entering into a full-fledged dialog with the author was very
difficult on paper, but should be easy now that readers can respond quickly and visibly. A reader creates a new link, or crafts a
guided tour, or writes an overview which transcludes (
transparently includes or embeds) quotations from a difficult source (making it more accessible). This should
initiate a cycle of creativity; but it does so far less frequently on the Web than
In such acts the reader becomes something more — but what, exactly? Possibly a reader
responds is different; but that seems to me a matter of quantity, not nature. Certainly anyone
who writes is
an author. All authors are, in the end, responding to others who went before. Whether a reader
responds by scribbling privately in the margins, recommending edits to a co-worker,
or writing a best-selling full-length critique that touches off a new field of study,
they are an author. But essentially zero-cost networked publication brings a new dynamic:
the ability to sustain a cyclical, multi-party, rapid, interactive, visible conversation
— as Kant (though far more slowly) published Critique of Pure Reason (Kan81) and others responded, in turn prompting Kant to re-respond with the Prolegomena (Kan83). In the world I am trying to sketch, this is the norm. The size, value, and influence
of each contribution need not be constrained by its author's predefined role.
Current technology is better characterized as permitting such interactions, rather than actively enabling and encouraging them. And yet hypertext
pioneers were intensely focused on readers as active rather than passive agents, and
on collaborative work in which the roles of author and reader blur, even when there
is a particular work by a particular author being discussed. An adequate history even
of early hypertext is far beyond the scope of this article; but a few highlights may
illustrate this fundamental focus:
In 1945 Vannevar Bush envisioned (but did not build) electronic libraries with high-speed
search; the ability to make bookmarks, annotations, trails; data entry via a forehead-mounted
camera; and information sharing (Bus45).
Doug Engelbart built NLS and Augment, which were used for collaborative document work,
outlining, shared links, and more; not to mention inventing the mouse and the window
Ted Nelson and Andries van Dam designed HES, with implementation by van Dam's team
of undergraduates (led by Steve Carmody), while van Dam and his team designed and
implemented FRESS. Both systems supported large documents with styling, reflowing,
linking, and more; FRESS was the first system to implement
undo. They were used for book production, collaborative writing, and for primary texts
and student discussions in classes (Yan85, DeR99, van87, Bar13).
Ted Nelson's Xanadu (Nel81, Nel99) aimed for a world where works are primarily electronic, with persistent identifiers
that can be precisely referenced without breakage — even in the face of edits. This
single feature greatly mitigates several of the most vexing questions in hypertext
functionality: link breakage, universal identifiers, transclusion, micropayments,
and even some security issues. Xanadu (through a data structure called the
enfilade (Uda99)) had the extraordinary property that the
address of a given piece of text remained unchanged even when the text was edited. This requires
overhead that seemed infeasible at the time, and the enfilade never caught on. But
in principle it is feasible; strong document-versioning systems are described in Dur08, Ven12, Nic95, and others, as well as a wide variety of more recent and/or less document-oriented
The Engelbart, van Dam, and Nelson systems bring us only to the late 1960s. The following
20+ years brought tremendous activity and creativity. Systems structured around collaborative
reasoning and decision making such as gIBIS (Con87b, Con01) appeared; distributed hypermedia systems such as Intermedia (Yan85); and much more. Very few of these systems were delivery-only; most envisioned very
active, productive, collaborative readers. Hal87, Hal01, Wei87, and Con87a provide extensive review and analysis, still valuable today. Bar13 provides a highly-regarded historical survey of the hypertext field.
These issues remain critical today, and have had much attention in some quarters.
Yet online publication rarely takes much account of versioning (Wikipedia being one
of the exceptions). HTML's <del> and <ins> elements remain essentially unchanged,
lacking even conventions for version-identification, much less integration with version
control systems, end-user view control, and linking. A trivial and obvious improvement
in browsers would be to provide a view switch that responds to them; at the CSS level,
convenient means of supporting the equivalent of red-lining; at the HTML level, a
means for links to refer to named change-sets and versions (and, at a minimum, warn
if the target has changed, which can be done merely by allowing checksums to be kept
with links in a standard fashion); at the standards level, WebDAV (Dus07) already provides some versioning mechanisms (Cle02, sometimes known as
DeltaV), but support remains limited (SVN hooks are available for some features).
The impact of word processing
As personal computers and word-processing spread, Ted Nelson noted that
To the best of my knowledge most of the present generation of word-processing programs
derived from the Brown System [HES] — but lost the hypertext part (Nel87b, p. 28). However, Chuk Moran, in his 2013 UCSD dissertation, disputes this (as noted
by Rosemary Simpson in personal communication). A number of hypertext experts later
worked on important WP systems, but somehow virtually no WP systems have made non-trivial
use of links. Because of the ubiquity of word-processing, many users already hold
notions and models from word processors when they begin learning how to author hypertext;
thus lack of key features, or allowing them to be needlessly difficult in WPs, makes
those features much harder to
Some word processors have, indeed, provided section cross-references (but very few
can do them easily across files); many provide tables of contents (but even now they
are commonly dead). Once saved to PDF, ToCs frequently become non-functional, and
go to page N feature found in PDF viewers is badly broken, because it counts only physical images,
not logical pages. Properly speaking, this page-counting is more the fault of applications
that generate PDF than of PDF itself; it could be fixed.
Along with links, word processers lost the idea that documents have some hierarchy.
Chapters, sections and the like were eliminated as structures, in favor of having
only headings. Certain aspects of SGML (Int86) such as the Annex D sample schema (of which HTML is reminiscent) and certain minimization
rules, may have done too little to push back against this problem. Lists in word processors
are rarely first-class objects; only list items. This facilitates the fiction that a document is little more than a sequence of paragraphs
and character-runs within them. HTML5 (Ber14) is considerably better in this respect. Everything larger was decoration (such as
page-breaks) or special cases (footers, tables, etc). This model fails to account
for many real phenomena, and therefore leads to anomalies such as the varying but
ever-present problems editing nested auto-numbered lists, odd behavior at the boundary
between paragraphs of different styles; editing in
outline views, and so on. Natural units larger than paragraphs are not first-class objects
in the software's model, so WPs can only support them with (generally hidden) heuristic
rules, leading to opaque and unintuitive behavior.
It is not difficult to find correspondences between the weak models applied in word
processors, and limitations in the current Web. While appearances are very important,
a naive dedication to appearance at the cost of ontology is self-defeating; most modern
authors have experienced this when, having spent many hours refining the appearance
of their writings, they are blind-sided by new costs:
Commonly, the appearances must suddenly change due to publisher dictates, delivery
medium limitations, or the need to represent distinctions previously missed (say,
bolding option names while italicizing option values in documentation, rather than
treating both the same).
In more severe situations, achieving a desired appearance with inadequate tools to
map structure to appearance, leads authors to conscript irrelevant structures to achieve
their goals. That is not the fault of authors fault when it is difficult to achieve
the desired appearance perspicuously. Rather, authors have fallen victim to one of
the classic blunders — the most famous of which is using tables for formatting.
With some authoring systems, details of their model
HTML has gradually been stepping back from this precipice, and HTML5 continues that
movement. Yet even now we seem almost to have a parody of Kant's contention in the
Critique (Kan81, sec. 9):
What may be the nature of objects considered as things in themselves and without reference
to the receptivity of our sensibility is quite unknown to us. But that is not the case here. Web pages do not purport to be "things in themselves",
but the products of cognition. Also our perceptions of documents are not merely of
layout and typography — we perceive a great deal from the language used, the organizational
conventions, the author's use of our prior knowledge of the topic, and much more.
With documents, our goal is not so much to engage with a "true structure" of the text,
as to engage with the propositions asserted of the text by prior contributors (including
the nominal author(s), but as easily editors, annotators, or respondents). See for
The further that document models depart from such cognitions (or, more precisely,
the further that systems push contributors away from direct expression of their propositions),
the less intuitive our systems become. This can be a virtue, just as subverting literary
conventions can be; but that takes great skill. Far more commonly, we simply encounter
bizarre behaviors: problems selecting exactly a paragraph or section; difficulty of
accessing multiple links from a single origin anchor (or such opportunities being
absent); the inability to get and use a precise reference to a given selection; the
difficulty and even occasional risk of quoting or linking other works; the near-impossibility
of engaging with an author at any granularity better than "web page"; seeing our responses
(or even our purchased ebooks!) simply disappear from sites beyond our control.
How is it that such useful, proven features as links, live ToCs, and bookmarks were
almost entirely lost in the WP domain? Or that chapters, sections, and lists were
reduced to epiphenomena? It has often been suggested that an intense fixation on
WYSIWYG appearance left out anything that wasn't fully
paper-like (such as automated links, hot ToCs, and so on). That is likely a factor, but does
not explain the omission of bookmarks, scribbling in the margin, and so on — unless
what you see exclusively from the nominal author's perspective. Late in the history of WPs, rudimentary
change-tracking and bookmarks were added, which at least facilitate primitive collaboration;
but these remain mere shadows of functionality from the 60s, or even from the paper
Ted Nelson characterized the early Macintosh, with its WYSIWYG approach now characteristic
of most commodity word processors, as
a paper simulator — millions of acres of virtual pressed wood-pulp. It's the deforestation
of the American mind (Inf87).
The Web began in the context of extensive hypertext research, ubiquitous word-processing,
widespread network access, and SGML. It became ubiquitous almost overnight. It nicely
leverages the Internet itself, hierarchical filing systems, personal computers capable
of good rendering, and a markup system which (while rudimentary at first) was abstract
enough to permit data portability. If you didn't have italics, or color, or a certain
size screen, or even a screen at all (for example, having voice synthesis instead),
you could still use the Web. Putting up a Web server required little more than getting
a domain name and copying over some directories and files.
Like much else, hypertext R&D was redirected almost overnight to use the Web as its
underlying infrastructure. Before long even ACM SIGHyper was renamed SIGWeb. But for
all its strengths, all its success, and very substantial growth in functionality,
the Web in general — and HTML in particular — still lack some compelling, useful,
democratizing, and powerful features of earlier systems.
However we explain this historically and technically, it seems odd that some very
basic features (present in nearly every prior hypertext system) were left out of the
Web, and remain missing even today except for specialized, custom, private additions.
A few of these existed or were planned in some early Web tools, but quickly disappeared
(Cai99). Many others have been repeatedly rebuilt, but failed to become widely available.
This could be caused variously by technopolitical conflicts, insufficient perceived
return on investment, a sense that content shared on a site not your own may be lost,
or, perhaps most likely of all, the ease of motivating (and advertising) building
a new ride rather than building (as Renear aptly put it), the tunnels under Disneyland®.
I am not speaking here of the famous breakability of links specified by URIs (on which
see below). Nor am I speaking of the arguably superior aesthetic qualities of paper
(resolution, color, texture, reflectance, etc.). Rather, I am speaking mainly of the
failure to share power for readers as opposed to only (nominal) writers. For millennia
readers have had highly flexible, trivially simple tools and capabilities for responding
to what they read, although sharing their responses was far more difficult before
computers and networking. Those same capabilities, plus far more practical sharing,
were central to the visions of all the earliest hypertext pioneers and were reflected
throughout their systems. Yet open a page on the Web, and nearly all such capability
is gone, or available only in a few special places.
Although improvements have been made (and still can be), link breakage has never been
fully solved, and may indeed be insoluble.
Readers on the Web have the freedom to choose among whatever links the author thought
to provide, or to travel further afield via a search engine; but they have little
capability to respond, much less to share:
It is difficult for readers even to accomplish the most basic response of the paper
world: scribbling in the margin. They can, of course, put their notes in a separate
file — but that is not at all the same thing, for the note will not be there when
the reader returns to the relevant Web page, and the Web page may have changed in
the meantime, possibly making the note obsolete or even nonsensical; readers cannot
even verify whether the Web page has changed or not.
Many individual websites do address the demand for reader response, at least in simplistic
fashion: Amazon reviews, comment threads on news sites and blogs, FaceBook comment
threads, etc. However, these are highly constrained (in length, formatting and linking
capability, and accessibility), constrained in site-specific ways, isolated from
real content (perhaps exiled to a small scrolling box, with no means of attachment to
any place more precise than an entire article), and supported only at the pleasure
of the site owner. Readers may even be asked to give up legal rights to their writings
in order to post. With popular sites and topics, comments rapidly disappear no matter
how cogent (some sites such as stackoverflow.com, for whom high-quality answers are
a core value, address the last-mentioned problem by moving up-voted postings to the
top, and in other ways).
With sufficient effort and skill (far, far greater than that of the average reader
of paper or screens), reader can create their own sites, just as print readers could
publish a rebuttal or paean to a printed work.
The relationship of author and reader is often as asymmetric on the Web as in the
paper world. It is not my goal to discuss the causes of this, but possibilities to
consider might include companies feeling a need to protect their image (as perhaps
in a lawsuit over a negative review posted on Amazon — Vas14); pessimism over the value (economic or other) of reader contributions; fear of enabling
"trolls"; an online culture now used to such limitations; and limited technical sophistication
Perhaps the saddest demonstration of reader disenfranchisement is that there have
been numerous lawsuits for linking to things. Not copying; simply linking. This goes far beyond failing to give readers
what one gives writers; it takes away one of the most basic freedoms one has on paper.
Suing someone for linking to your site is in my opinion exactly like suing someone
for citing your article in a footnote or bibliography — that is, completely nonsensical.
Fortunately a variety of courts agree (summaries of several cases are in (Bod04) and Wikipedia topic
Copyright aspects of hyperlinking and framing).
Wikis are a notable and very important exception, where readers do have great freedom
to contribute. On the other hand, Wikis might be said to overshoot the concept of
dynamic dialog between authors and readers, because they not only empower readers
but almost lose the notion of authorship at the same time. While many users can make
changes, there is little or no provision for distinguishing
the text from
the response (and of course, the response to the response, and so on). Wikis that retain the change
history could support such dialog even in the face of change to the underlying text;
but I know of none that integrates a notion of discussing the text with the editing
or structure of the text. For example, Wikipedia provides an immensely useful discussion
page for each main-entry page, but the discussions there have little provision for
temporal, topical, or rhetorical structure. Points made in the discussion cannot easily
be connected with the portion and version of the text they refer to, and a Wiki provides
little help for reading the discussion in context of the text portions being discussed.
Users are resourceful, and find ways to work around limitations: They quote (usually
without linkage, for precise anchors are unaccountably difficult to achieve), even
though their quotes become obsolete. They may pull up a page's version history and
seek out changes that were made around the time of a given discussion point (surely
a task crying out for automation!). Some sites archive historical versions of Web
pages, which also helps. But there is clearly no technical reason contributors can't
be enabled to comment on specific places in an article, or to see the discussion right
alongside the text it involves, with integrated viewing of suggested or executed changes.
Such interfaces have existed for centuries in the humanities, though the cycle of
republication and distribution of annotations via paper was very slow.
A fundamental issue
Electronic publication raises one special problem that is far less apparent in the
paper world. Information has no stable form. An inscription, scroll, or codex is difficult
to change without it being obvious. An electronic document can be changed or removed
at any moment, with essentially no trace. We have become used to links breaking, but
also to text changing out from under us. This leads to many problems, and is very
hard to solve definitively. Some of the responses include:
Saving a local copy of things you may want later (but this may not be "connected"
to the original; Mac OS X at least stashes the source URI of downloaded files as file-system
metadata, which helps a little).
Taking a screenshot. With AJAX the data you "save" may not resemble what you see on-screen,
nor include enough information to re-fetch what you saw. One amusing case is mis-placement
of ads; since ads are usually served dynamically, going to the same URI later, or
re-opening a saved copy of the page, won't reproduce the mistake.
Archive sites such as The Wayback Machine (http://archive.org/web/) try to keep old versions of Web pages.
Trying to keep links to documents on sites that seem trustworthy, such as long-established
publishers, archives, or institutions, or sites that offer "permalinks"; rather than
linking to copies on transient sites.
A very few sites, thankfully including Wikipedia, maintain and provide extensive version-history
Some authors attempt to keep section numbering, section titles, or IDs as stable as
practical across revisions. Regulatory and legal information sometimes involves elaborate
systems to enable durable reference.
Many software distribution sites provide a checksum for each download, enabling users
to check that what they got, is actually what they asked for. This is not perfect
security, but does guard against many problems.
Simplest of all, many sites make a practice of including a "last modified" date near
the top of every page. If bookmarks and links also included such a date, at least
in good-faith situations the returning reader could be warned that the page has changed
(whether or not the change matters to the reader is, of course, another matter).
The problem of transient information does not only cause "404: Page not found" errors.
Much more pernicious is getting a page which seems the same, but includes changes
that make your link or annotation nonsensical. We cannot keep pages from going away
or being rewritten; nor would we want to. However, it is entirely practical to make
sure people can tell when that has happened. Stashing a checksum and date with a bookmark,
or with a URI copied from the browser, requires neither difficult technology, nor
participation by ISPs, websites, or anyone else; it can simply be done in browsers
and other user agents. For sites that support versioning, of course, stashing the
version identifier of the linked page is also helpful.
This protects against changes that make your link irrelevant even if not strictly
broken. It can also be used to protect against certain kinds of spoofing, such as substitution
of malicious data in place of transcluded content.
Not all links should point to the original version of their target. A link to a stock-price
could be intended to refer to the price as it was when the link was made, or to the
price as it is whenever the link is later followed. This is a legitimate distinction
of intent, so forcing either choice will be wrong sometimes. At present, however,
our technology forces the latter.
How does electronic publishing fit in?
Publishing in the electronic medium, for all its advantages, loses some benefits of
prior media: Computer files do not last nearly as long as paper (much less granite),
at least without active maintenance. CDs and flash drives don't smell nice or have
engraved leather covers that may themselves be works of art. Ebook readers are not
so cheap that dropping one in the bathtub is stress-free. Undesired Kindle ebooks
do not make good kindling. And no ebook platform yet makes it as easy to annotate,
dog-ear, or draw circles and arrows and a paragraph on each page, as it is with a
$0.99 paperback and a $0.25 pencil.
The obvious response to such limitations is to make the most of advantages electronically-published
works have in other areas. And indeed this does happen in a few ways: ebook readers (especially networked
ones) provide ready access to far more books than one can carry on paper. When provided,
cross-references are far quicker. And accessibility for visually impaired readers
is often far better. Occasionally an electronic publication may contain video or audio.
Ebooks have implemented some significant improvements: changeable font size, immediate
downloading, and the occasional audio, video, and links are very helpful. Nevertheless,
electronic publishing has made fairly little use of the potential advantages of new
media. I suspect this is due to a few simple but pervasive factors:
Many publishers still view a print edition as the primary thing. They spend a great
deal of time and money carefully crafting details of appearance, with tools optimized
for manual attention to every aesthetic detail, by skilled craftspeople (the Typographers
Guild?). Features specific to electronic books have no clear place in such a process.
Low customer expectations for the aesthetics and functionality of ebooks likely help
support this dysfunction.
Most authors use popular word processors for writing, and even today most such tools
actively discourage practices that would help. Thus, authors have less motivation
to create useful structure in their works; even if they do so, the conversion to many
publishing systems discards nearly everything but the raw text content and basic formatting
(say, italics, bold, headings, tables, and footnotes).
At some point, the electronic version
forks from that destined for paper. Many, many publishers base the electronic version on
page-production files that may have already lost or obviated structural information
the author put in (in other cases, the author provided little such value to begin
with); however, they tend not to base the electronic publishing version on the final version of those files. Countless small changes are made afterword, and publishers
find themselves in the untenable situation where the paper and electronic versions
simply do not match (in content — readers expect differences in layout and rendering).
Indeed, this problem was discussed in The Economist (Fle14) recently (though without discussing alternatives). Ill-suited as they may be for
non-line-based documents, even basic source-code version control systems would make
this process somewhat easier, as would wider support for the
These days, word-processing and hypertext have partly converged: Most word processors
can import and export XML or HTML (though it may be unconscionably messy), and many
even let you you click on inline URIs. Very few capabilities clearly belong in only
WPs or only hypertext systems; yet word processors typically support only the most
trivial hypertext features, and even the main Web technologies (short of custom programming)
remain very limited with respect to hypertext authoring. The first Web browser was
also an editor (Berners-Lee, undated), and NetScape Composer seemed a promising integration
of reading and writing. It is not clear just why editing and browsing have come to
require separate software, but this split surely contributes to the separation of
readers from authors; fluent browser users can't just learn a few new things to become
full-fledged authors; they must choose and learn an entirely new application and interface,
and may be tripped up by the fact that some authoring systems create HTML that is
difficult to deal with outside the originating program.
As for hypertext per se, present users may be so conditioned to what a
link is in a Web browser (or even a word processer), that it has become hard to imagine
that anything could be different. But much could be different; much is still missing.
Before I discuss specific missing features, let me anticipate a response. To almost
any lack, a Web developer could respond
but you can build that on top! That would be right: There are Turing-complete programming languages, most obviously
just as true before the Web existed (that's how the Web was built, of course). The
difficulty is that with the Web being the ubiquitous environment, anything that it
doesn't provide (via at least several browsers) has little chance of broad general
use. A feature that only works on certain sites, or with a certain set of plug-ins,
or if you follow special conventions, is a 2nd-class citizen in the world of information.
Because you can't count on a significant share of users having a given plugin, access
to a special proxy or annotation server, etc., it is very hard for such features to
be widely used. Consider the erstwhile impoverishment of Math on the Web: until nearly
every browser got MathML support, it wasn't feasible to use math except via images
(<object>'s fallback mechanism helped, but wasn't around very much earlier).
On the Bounds of the current Web
In this section I discuss several basic capabilities that are largely absent
from the current Web, though they are fundamental parts of hypertext and computer-supported
cooperative work (CSCW) in general. Yee provides an informative discussion of several
of the same issues (Yee02), and Bieber et al. (Bie97, Section 3) provide an invaluable, detailed analysis of many such missing features,
categorized under these headings (p. 36):
Typed nodes and links
Link attributes and structure-based query
Transclusions, warm links and hot links
Annotation and public vs. private links
Computed personalized links
External link databases and link update mechanisms
Global and local overviews
Trails and guided tours
Backtracking and history-based navigation
The reader may find it useful to compare their analysis to that of this paper. I enumerated
the categories below before encountering Bie97, yet the concepts called out are quite similar in both.
On the current Web, users do have a few degrees of freedom they lack with paper publication:
they can resize the window (and most sites will re-wrap appropriately); they can adjust
the font-size. In Safari at least, they can switch to an alternate layout that may
be better for reading. If they are sophisticated enough to find, install, and use
add-ons, they can do more, but rarely cross-browser and cross-site. And that's about
technologies. Should a reader master all those, few of the skills transfer to common
authoring environments (for example, customizing OpenOffice requires different languages
What could readers do in a better world, that they basically cannot now?
As noted earlier, a key goal of hypertext has long been collaboration: readers are
also authors, and they naturally should have the privileges of authors: to share their
creations with others; to be able to use prior author's work in all the usual ways
(some of which require permission or compensation, and some of which don't); and so
Nearly all of the following features facilitate collaboration. Some of them (such
as trails) can be provided by authors; but that is not the point. We have all seen books for which
a good index would have been invaluable, but the author didn't provide one. No doubt
they could have, given time, money, skill, and/or inclination; but many have not.
As well, it is simply not possible for authors to anticipate all the needs of a diverse
readership. It is in the very nature of hypertext, that readers must be able to do
authorial things too. We all should benefit from the annotations of others.
The current Web essentially lacks annotation. Users cannot make notes, highlights,
or links even for their own private use, without finding specialized software. Current
bookmarks are not a solution: they only point to the whole document (comparable to
having no margins to scribble in on paper, but only the inside front cover). Bookmarks,
especially when AJAX is involved, may also exclude state information required to get
"back" to where you are. Bookmarking not only fails to do what the user expects, but
fails quietly. One can easily make any number of bookmarks while browsing an AJAX-heavy
site, only to discover months later that they all lead to the same cover page.
The AJAX "state" problem is hard to solve in the general case. However, browsers could
trivially let users attach notes for their own use (without, of course, having to
modify or copy the original document). Reader-created links are also easy. Shared
annotations are harder, but not that hard. The usual model is to support some kind
subscription to shared annotations databases, so users need not be overwhelmed by every 9th-grader's
insights on Orwell's 1984.
Several projects have built
Web annotation systems, such as CritLink (Yee02), Annotea (Koi05), SharedCopy (http://sharedcopy.com), and Marky (http://sing.ei.uvigo.es/marky/index.html). However, most have been short-lived, and none have gained a substantial following.
To my knowledge, most or all of them have required inconvenient schemes such as centralized
annotation servers, using a proxy or proxy-like 3rd-party server for sharing, copying
documents that you annotate, or similar. All have shared the problem of being add-ons.
How many people would scribble in the margins of paper books if doing so required
a special pen, available only at specialty stationery stores?
Far more useful than notes attached just to pages, are notes, bookmarks, and/or highlights
attached to precise locations.
The technology for linking to precise locations has been around for a long time (XPointer
During XPointer development there was opposition from a few who claimed that browsers
would never be able to implement keeping track of an arbitrary location in a document
— usually the
impossible case cited involved the user dragging from the middle of one paragraph to the next.
Of course browsers have all had a
selection notion since the beginning, which does exactly this; most have by now implemented
In my opinion, this is the single most blatant and single most damaging omission in
current Web technology. Without a widely understood and used way for readers to point
specifically where they want to, readers are limited to linking only to points that
have IDs — and the author is in total control of that. Not only that, but even finding
the IDs that do exist (if any) requires considerable expertise, and Cailliau and Ashman
(Cai99) point out that browsers have, inexplicably, ceased even to highlight the target
element, making precise linking far less useful even when IDs allow it. Basic UI principles
such as not scrolling the target to the very beginning of the window, but rather showing
a bit of prior context, seem beyond reach.
The single most fundamental interface, common to nearly every hypertext system ever
built (except the Web), is to select a range in a document, and make a link to or
from it. But users of the Web cannot do this even now. Even when authors provide IDs,
readers cannot use or even see them with unusual sophistication; and even then HTML
link targets are at best points or possibly elements, not scopes or selections.
Having a server handle this is possible, and many specific sites have implemented
gadgets for special cases of it. But that does not touch the fundamental problem.
Besides working only on a few sites, or with certain browsers or add-ons, or on alternate
Tuesdays, it still leaves those sites in control — not the reader, who clearly owns
any annotations they create (and may wish to keep them private).
Bidirectional linking is considerably harder than annotation or precise linking. If
a million people create their own links to a certain page, whoever serves that page
cannot be expected or compelled to add a million links back. However, bidirectional
linking can be very valuable in more controlled contexts, such as within a workgroup
or any other community with shared interests. There should be trivial, standard ways
to set up such a group, share links with members, and ensure that such links can be
seen from both ends. This is not hard technologically; but it is hard for publishers
to like, as it limits their control.
Bidirectional linking makes it obvious that links must be able to reside outside the
document(s) being linked. However, that is already necessary for any non-authorial
linking — unless you copy the document, which introduces many other problems, although
it avoids (without entirely solving) the problem of the document changing. Cailliau
and Ashman (Cai99) note that link authoring was made to appear difficult and to require specialized
tools, due to shortcomings in the Mosaic interface, but that
arbitrary link authoring has been considered a key feature of hypertext systems, ever
since their first inception, when Bush described the creation of associative links
to record one's path of reasoning through a library of information.... They also point out that
Third-party linking epitomizes the contest between free speech and reputation, or
perhaps between graffiti and propaganda. However, there is clearly much benefit in
the technology. The Web has no
quality control office, so anyone can (and frequently will) put up materials of questionable integrity
and authenticity. The very vastness of the Web now means that it may be impossible
to find evidence to support or deny questionable claims, so properly-used, a third-party
linking technology can effect a highly democratic form of quality control for the
Transclusion is simply
transparent inclusion: Embedding part or all of one document into another. In the early Web, I was frankly
shocked when I discovered that <img> (which did embedding just fine for pictures),
simply did nothing if I pointed it at an HTML file instead of an image. Far more shocking
is that 20+ years later there is still no easy way to do this. HTML 5's seamless iframe
makes a start, and specifies a number of important semantic details. On the other
hand, without precise linking seamless iframes are much less useful, and the interaction
even with trivial fragment identifiers seems unclear.
When transcluding a document, there are three levels of "scope" that might be specified:
The destination anchor itself, to which the user's attention should be directed, for
example by highlighting; the amount of surrounding scope that should be available
(the size, zoom, and scrollability of the display area can serve as a proxy for this);
and the total amount of the target document that should be accessible (for example
via scrolling). More sophisticated details such as whether/how to show author and
version information about the target, give direct access to other versions, and so
on, may be more than need be standardized.
Transclusion, particularly when formatted to appear seamless, makes issues of attribution,
legitimacy, and spoofing more obviously important, but likely does not actually introduce
any new problems along those lines. The same effects can be achieved (like most anything)
with sufficient server- or client-side programming. People doing malicious spoofing
Dynamic views are alternate layouts that can be switched at will. Style sheets are
the obvious way to achieve this on the Web, but have not nearly achieved their potential,
which is far wider than their present use. Probably their first important
selling point, starting in the late 80s, was as a way to factor out formatting. Authors would instead
kinds of document components, enabling the publisher professionals to do layout far faster,
and to respond to last-minute changes (Coo87). This let publishing staff change a definition instead of manually changing every
instance (in this, it is like many uses of indirection in programming). This the Web
understands well, even if many authors (and some authoring software) do not.
Stylesheets became more important when large documents began to be delivered in electronic
as well as paper form. Notable early examples included aircraft repair manuals, and
online documentation for SGI, Novell, DEC, Sun, and others in the early 90's. In such
settings documents came to be
multipurposed: for print, for CD and online delivery, and perhaps other media as well. A document
with its print layout hard-coded required almost as much work to convert for online
delivery as it took to make in the first place. A structured document with a separable
style specification need only have a new style sheet installed. CSS now provides much
of this benefit, particularly for the browser/print split, even though print formatting
remains limited, as do features needed for tablets, dedicated ebook readers, and smart
The gradual removal of purely format-oriented elements from HTML, and the addition
of new constructs that make it easier to avoid
tag abuse (most notably overloading of tables, lack of math, etc.) have been excellent moves
forward. Structural markup as opposed to format-oriented markup provides the "hooks"
that make dynamic views far more valuable. Microformats for ubiquitous Web components
such as addresses, product information, and many more would be useful additions, but
there is plenty of descriptive information already in place that can be leveraged.
As a side note, it seems amazing that HTML and its added functionality have not taken
man pages. There remain many viewers, though
less is probably still by far the most common. Few viewers even support rudimentary links
within and between man pages (
info does a little). Imagine if man pages were marked up better, for example by identifying
option names and types (an achievable though not trivial conversion). It would then
be simple (among many other things) to auto-generate forms from the documentation.
You could not only read about options whose names or magic values you've forgotten,
but click on them right there in order to interactively assemble the command-line
you need, or sort them by categories, alphabetically, by interdependencies, or other
ways as desired. Most of this could be done with existing style technologies once
the source data was cleaner (an eminently affordable or even crowd-sourcable task)
— though see also the section on Integration of Linking and Style, below.
A third value of stylesheets remains missing. We still tend to think in terms of
one style sheet per medium. We know that if you're on paper, you deserve a special style sheet; likewise if
you're visually impaired. Some websites provide an alternate view for phones (usually
via browser sniffing or a special sub-domain). But the mechanisms for publishing to
cell phones remain awkward, and almost entirely outside the reader's control — I cannot
rely on any particular accommodation when on my smart phone: it all depends on which
sites I go to. I can't even change font size readily as I can on a laptop (though
it's even more important on the cell phone) — other than by zooming, which breaks
all the lines and makes the page unreadable. Ironically, this is almost the same problem
many of us fought with for years, when publishers demanded multi-column layouts and
pageless scrolling at the same time.
We must ask ourselves at least two questions: 1: Why should there be only one stylesheet
per medium? And 2: Why should it only be practical for authors, not readers, to create
and swap stylesheets at will? In some browsers I can install my own stylesheet that
overlays everything; nice for a few things like font size. But the flexibility is
View menu provides for choosing among multiple stylesheets if available, though it's not
obvious whether or how end users can add their own. As noted before, the reader is
largely a second-class citizen, expected for the most part to passively accept what
websites provide. Web designers in turn, can be under pressure to design for the least-skilled
user, leading to a pernicious cycle of low expectations.
Systems as early as FRESS provided easy ways to change styles at will, and not merely
by swapping entire stylesheets. In short, any element in a FRESS document could have
a list of keywords attached, and users could at any time set a
keyword request string, which was a Boolean expression over such keywords. Only objects which satisfied
the request string were operative. This was not nearly so easy to author as it would
be now, since FRESS did not have stylesheets as separate first-class objects. Nevertheless,
once set up it was easy to use, and many users found the capability useful enough
to keyword their documents heavily, allowing many of the same effects as swapping
stylesheets on the fly. See DeRose and van Dam (DeR99) for further details.
Roderick Chisholm wrote many of his books in FRESS. He commented in the Preface to
his classic treatise Person and Object that
The book would not have been completed without the epoch-making File Retrieval and
Editing System... (Chi76). In classes taught with FRESS, keywords were used to hide students' comments and
annotations from each other (but not from their TAs and professors) until they had
completed a given section of work; and then to open up the discussion.
In fact FRESS's filtering supported not only keywords, but also variables with values
and even weights. One user even created a faculty salary database (and there was no
scripting language in FRESS, so it was entirely declarative). Imagine if it were standard
functionality on the Web, to be able to create live tables much like spreadsheets.
tasks that countless spreadsheet users already understand and do regularly requires
substantial additional expertise (or commitment to specialty add-ons); it is extremely
difficult if you aren't the author of each particular document. It would not be hard
to enable spreadsheet-like tables in HTML (for example, by some new CSS property)
— but real usefulness would require a bit more, such as simple forms integration (where
simple means no programming).
Merely being able to attach all the style sheets you want to documents and switch
between them at will, would be a huge step forward yet trivial to implement. In practice,
some would be from publishers, some be of your own making, and you might choose sets
to apply by domain, something like cookie white-listing. As noted earlier, various
browsers have some parts of this functionality, but little to none of it can simply
be expected to work as a matter of course.
Ted Nelson (Nel81) proposed an even nicer (though more challenging) feature: A
StretchText control (perhaps a knob or slider?) to dynamically adjust the level of detail desired
in content itself. If we had several of the other capabilities described here, this
would be fairly easy to build atop automatic text summarization systems.
Dynamic (rule-based or implicit) linking
DeR89 discussed the division of links into
implicit. HTML <a> is the quintessential explicit link: there is an explicit representation
of the origin and destination (though both appear only at the origin). But situations
often arise when it is valuable to have all occurrences of something linked. Implicit
links address this need without having to manually link every occurrence of a word
(or phrase, or regular expression match,...). Instead, a pattern is specified, and
the system finds all matches and links them.
For example, when reading a Wikipedia page on an unfamiliar technical subject, having
links from jargon would be very helpful. But whether such links are valuable or merely
add clutter depends on the reader, not mainly the writer. Because the existence of links cannot adjust for this, Wikipedia articles often
have too many or too few links — this is typical with explicit links because readers
vary (although Dynamic Views as discussed in the previous section can be used to similar
In much the fashion of regular expression
captures, a rule can include part of the matched text into the URI generated for the implicit
links, allowing you to define large sets of links with a single rule. This is especially
good for linking things such as Named Entities (regarding the detection of which much
research and software exists), technical terminology, and so on. Given such functionality,
one could also avoid endless repetition when the anchor text of a link is the same
as the tail of its URI — a simplification featured in Wiki markup, POD, and other
Implicit links make inevitable, a useful but rarely-seen capability: being able to
reach multiple end-points from a single source anchor. If many implicit links are
enabled, this becomes especially important. But even with only a few, and even with
purely explicit links, it is often useful to have multiple options: Do I just want
a reminder of who Neville Chamberlain was, or a whole article on him, or an explanation
of how he relates to whatever article I'm reading now? Intermedia (Yan85) made extensive use of this capability; the basic interface was a pop-up menu of
the links available from the current point. Similarly, on seeing a reference to a
supporting article I may want to see the citation information, or the abstract (perhaps
in a small pop-up), or actually go to the full article. This capability is synergistic
with precise linking and with transclusion.
It would not be difficult to let links be annotated (manually or even automatically)
as, for example,
beginner (this could even be done with existing attributes such as
class). Empowering the user to turn the visibility of links up or down to match their expertise
level would let them customize and improve the reading experience. Users could even
set up profiles indicating their level of expertise in various domains, and articles
could adjust automatically (as always, a manual override should be available).
One more strong example of the pioneering hypertext systems' focus on enabling readers,
block trail feature. A
block trail was a list of document locations, reified. Readers could add the current selection
to a block trail. A block trail could be a document on its own, or inserted in another
document, and of course could be shared with others. A block trail could be displayed
as a list of links (something like a site map or navigation bar), or use transclusion
splice the link targets (not the entire documents in which the targets reside!) end-to-end to create a new (virtual)
document — one in which all the component parts know where they came from. This was
an ideal tool for creating guides to other complex documents, overviews, and other
Today, a Web page can easily be authored which does a little of this: a list of links, perhaps with explanatory text in between.
However, the lack of precise linking makes creating accurate trails infeasible. Also,
visual transclusion remains difficult to achieve. Yet it need not be difficult; Cailliau
and Ashman (Cai99) note that the NeXTStep browser already had features in 1990 for creating
path documents with essentially this functionality. Simple interface changes such as "Copy selection
with reference" and "Paste as new waypoint" would be enough to be very useful; accomplishing
the same thing with a dozen mouse actions as must be done now, is quite simply too
tedious, particularly given the lack of precise linking.
Hypertext systems gradually developed interfaces for helping keep the reader oriented
in the complex space of documents and links.
Breadcrumbs on many Websites can help with this, as can site maps. However, graphical overviews,
trails such as just discussed, and other navigation tools are uncommon.
Given the huge scope of the Web, an additional feature could be very useful for
helping individual readers stay oriented, which was not anticipated by early hypertext
systems (so far as I know): Being able to record preferences about where to go. Many
large news sites include content from many staff, affiliated, or syndicated reporters.
A reader will likely prefer some over others. It may be difficult to ensure that a
reader detects new stories by a favored author (though authors or aggregators can
offer a subscription
push service, or readers can set up a search agent); but avoiding a reporter you've decided
you dislike, or who writes at a level inppropriate for you, is difficult. This could
be done entirely client-side by storing appropriate information locally. Since there
is, perhaps surprisingly, no standard way in HTML to mark up the author, normative
URI/DOI/etc., or other often-crucial metadata of a page, avoiding an author would
sometimes be heuristic; but likely fairly accurate nevertheless.
Integration of linking and style
While the Web has a reasonably clear model for what is
document, what is
style, and how the two are handled (essentially by HTML and CSS, respectively), there is
no comparably clear Web model for linking. The behavior of links is purely magical
in browsers: browser code knows the <a> element (as well as <img>, <object>, <link>,
etc.); knows that it is overloaded for source and destination (and how to tell which
you've got); knows the special expected behaviors. CSS can do little but change a
link's appearance with :link, :visited, etc.
At the 2nd WWW Conference (WWW94), one of the CSS principals commented to me that CSS could handle all the formatting
requirements for arbitrary SGML. This was clearly wrong, but CSS has made continuous
progress toward being able to accomplish the formatting requirements of HTML. By now
the expected effects of nearly all HTML elements (not to mention attributes) can be
achieved with CSS instead. However, exceptions remain. In certain specific cases, leaving behavioral semantics outside CSS is, in my opinion,
unproblematic. For example, there seems no point in trying to fit the functionality
of HTML5 <canvas> or SVG into CSS, rather than leaving them as magic. In particular,
this seems so because
the semantics are specialized, and only overlap slightly with those of other HTML
constructs (for example, in the styling of text within the drawing).
we could create all the CSS properties needed to make such objects declarative, but
I do not think those properties would see much use anywhere else;
nor would many of the existing CSS properties apply to drawings, beyond those that
do now for positioning them as blocks;
few people are likely to make tag-sets with such semantics for themselves.
drawings and their semantics are fairly self-contained.
Similar arguments apply to MathML, and perhaps to <object> or <form>.
On the other hand, linking semantics remains largely unaddressed in both HTML and
CSS. Unlike the previous examples, linking lacks compelling reasons to be separated
from CSS. Linking behavior is not nearly so specialized as vector graphics or equations;
linking behavior would naturally fit in CSS because it can reasonably attach to most
or all HTML elements (or selector-specifiable groups of elements); many of the existing
CSS formatting properties can already apply meaningfully to linking elements, and
many, many people already have other tag-sets with other linking elements, which are
notoriously difficult to get browsers to handle even when they are isomorphic to HTML
(which many are not).
Integrating a set of link-behavior properties into CSS would take the
magic out. Thus:
Browsers could support other tag-sets with minimal extra effort, rather than doing
so only for the
formatting capabilities of those tag-sets.
Linking would gain all the same
separation of concerns advantages that formatting gets by being factored out of documents into stylesheets.
Many asymmetries would go away. For example, right now <img> entails embedding, and
fails if it points to a non-image MIME type. On the other hand <a> is agnostic about
MIME type and can quite happily refer to images, but it implies non-embedding. <object>
is essentially like <img> except that it supports more types and has a fallback mechanism
(which, indeed, would be massively useful for <a> and <img> to have!). And HTML5 has
several similar elements, which it seems ought to share a factored-out set of linking
There are countless scenarios where particular components should change between being
links and being
regular displayed elements. <blockquote>, alt attributes, <del> and <ins>; <nav>, <aside>,
or even <dt> (especially on smartphones). This is synergistic with the notion of dynamic
views discussed earlier.
The semantics of link traversal usually involve only a few basic properties. Some
of these properties can have arbitrarily complex values in principle, but in practice
most needs are covered by a small number of cases; this is like many things that CSS
addresses. CSS can provide the key properties, as valuable for linking as those it
provides for other aspects of presentation. For example:
How the origin anchor appears. CSS has this, although it is at best awkward for non-text
ends such as icons, hot regions in graphics, menus for multi-destination links, etc.
What interaction event triggers traversal. The set of
onXXX event attributes address this, but seem out of place in HTML rather than CSS.
Possibly, some visual effects to go with the transition.
What happens to the origin location. Should it still be displayed or not? Should it
be rendered according to a new style, or collapsed to a compact form such as its top
Where the destination should appear. A few choices, such as defined already via HTML
attributes, should cover the bulk of needs.
How to determine the link's destination. Currently, names such as "a", "img", and
the like are magic, built in to browser code; so are the "href" and "src" attributes,
the meaning of "base", and so on. Any kind of document that doesn't precisely copy
all these names and their complex relationships, will not work in a browser except
via special programming. Even changes so simple as adding another linking element,
moving the URI (or base, or fragment identifier, etc.) to a different attribute, element,
or content — any of these exceeds available declarative (non-programming) flexibility.
Perhaps surprisingly, a new CSS property for this would need little more than CSS's
"content" property already provides: the ability to refer to attributes and concatenate
them with constants. Adding a function like attr(), but that takes an XPath or XPointer
expression rather than merely a name, would vastly expand functionality within and
beyond HTML, for minimal effort.
Parameters for how the destination should be viewed. This is not presently a part
of linking on the Web, but has been implemented in some other hypermedia systems,
and is especially important for transclusion. For example,
Traversal could set the stylesheet to be used at the destination, thus customizing
the appearance as appropriate for the context.
In a system with keywords that parameterize viewing (which could easily be enabled),
it is very desirable to support setting a viewing specification, such as an expression
over keywords, to apply at the destination.
XLink provides many of the needed linking semantics, but not all, and they are common
to the diverse systems that use XLink (SVG, XBRL, LC METS, etc.). The rest crop up
in many familiar applications, such as presentation applications.
One obvious way (but not the only way) to accomplish this integration would be to
evaluated in the context of the element to which the CSS is being applied. As noted
content property provides function-call syntax such as for attr(), so the required syntax
function-call such as often appears on HTML event attributes would suffice; more would
of course be possible. Although this capability might be supplied for only a handful
of properties, that seems to me as short-sighted as the early practice of giving DOM
access only to a few selected items such as links and form elements, or pre-HTML5
limitations of use of attributes such as id, style, lang, and the like. DynaText got
a great deal of mileage from allowing expressions as the value of all style properties (DeR99).
Another application of this kind of integration, would be for bibliographic references
such as in this paper. A key such as
Chi76 appears in content,
but is also sufficient to locate a target entry in the Bibliography. If you put the
key on an attribute then you can copy it into content with CSS's content:attr() feature
(although prefixed with
#). But if the key is actually in content, you can't use it as part of the URI without
resorting to programming. In practice, such cases lead to much duplication of data.
This paper is not the place to propose a full set of semantic properties out of which
the various linking behaviors can be built. However, that is hardly a new question.
Past hypertext systems have explored many possibilities (as has XLink), and coming
up with reasonable declarative semantics, plus clean scripting hooks, is not that
technically difficult. There will always be a small remainder of cases where arbitrarily
complex programming is required to get link behavior
just so for special applications — but that is no argument against integration, because it
is equally true for formatting such as currently done by CSS.
We have all encountered countless Web pages where someone decided that there was too
much information to show on one physical
page: forum comments on a controversial subject; a large textbook such as at http://pubmedcentral.gov; the list of people eager to meet you on a dating site. There are often good reasons
to break such lists up, but only rarely does a site provide any way to see all the
data at once. Bandwidth is rarely the issue, because transmitted page size often includes
more script than HTML (Eve13, based on data from http://httparchive.org/interesting.php).
On the present Web, however, you never know what you will find in terms of document
granularity. At some sites you can click a thoughtfully-provided
view as one page button; on others you can adjust the number of entries to show per page; on others
you must page through 10 or 100 or 1000 pages manually. If you want to actually see
the union, you can't just concatenate the files, either.
This is a significant practical problem: sending all the data at once is unwieldy,
but splitting it up into many parts is, as they say at ISO, obfuscatory. However,
this functionality could easily be standardized. This would let readers view things
how they want. Of course, sites that split things up for some special reason could
still do so; it would be quite difficult to prevent that even if one tried.
It is perhaps worth emphasizing that many sites implement such chunking via AJAX.
This works fine except that if you save the page, current browsers quietly save the
page source, which may contain absolutely none of the content you wanted. There is
generally no option to save the data as currently shown (except through developer
tools). What You See, in this case, bears little relation to What You Get.
In addition to the granularity problem, there exists information that is best delivered
in "card"-shaped chunks. This includes many simple database-like applications, and
also presentations. The hypertext research community long debated the merits of
creamy hypertext systems. The former broke information into small (card-sized) pieces. Both
approaches have virtues and limitations. Chunk-style information is tedious to achieve
on the Web, mainly because there are few provisions for making "cards" uniform; better
integration of XForms capabilities would help, mainly because of the notion of having
a fixed-form template, which is filled out with different sets of data.
On what can be done to make hypertext actual as a System
The reader will likely have noticed that these issues are synergistic, not independent.
They combine in a variety of ways to add extensive functionality, particularly for
active readers. I thus propose the following as some initial steps toward enhancing
HTML, CSS, and the Web in general to enable such functionality, and to come closer
to achieving one of the fundamental goals of hypertext systems: the emancipation of
Protect the right to link.
Make private, persistent annotation ubiquitous, and at least as good as annotation on ebook platforms. Better: Add sharing.
Make a way to point precisely without IDs, ubiquitous. XPointer is the obvious choice
for representation; select/make-link is the obvious interface.
Make it trivial to transclude a specified portion of another document (at least HTML
and XML) such that it appears inline, and gives ready access to the full original.
Use this to enable reader-created trails. One way to do this is to extend the CSS
content property, so it can insert not merely strings, counters, and attribute values, but
Integrate linking semantics into CSS — for all the same reasons. As a first step,
add all the HTML event attributes as CSS properties.
Make it trivial to attach a checksum to a link or bookmark, so the browser can say
if it has changed when you come back (there are some interesting issues with ephemera
such as ads, clocks, although some HTML5 additions such as the distinction of <main>
Make it much easier to attach style and script to documents
in the wild, and to switch stylesheets at will.
Introduce a keyword filtering capability, allowing stretchable, filterable displays
from a single source, under reader control. This could probably be done merely by
allowing expressions as values for the CSS
Provide built-in chunking (and un-chunking) capability that would make it easy to
build card-oriented sites when appropriate.
Most of these capabilities have been implemented and proven in multiple previous systems.
Many have also been tried on a small scale on the Web (via private scripts, add-ons,
special proxy servers, etc); but that isn't good enough for basic functionality like
this, on which readers so fundamentally depend.
While the Web has made huge strides in many areas, the humble <a> element has barely
changed in 20+ years. URLs have barely changed (except for the name and for the IRI).
CSS, while also having made great strides, still can't reconstruct HTML's default
behaviors (especially for links!). And massively useful functionality such as expandable
sections, keyword filtering, alternative views, synchronized scrolling, table sorting,
placing them beyond the average reader (one obvious example being the many un-sortable
data tables on the web).
Some of this, I believe, arises from an artificial separation between layout and interaction.
Interaction must (with a few edge-case exceptions) affect what is on the screen: a
fully-integrated synergy of content and layout. Yet interaction is presently segregated:
to affect it (other than the seeming anomaly of coloring links) one must learn and
tradeoffs: attaching onXXX attributes which are at least as anomalous in HTML as the
(which then involves knowledge of event triggering, timing relative to loading, event
bubbling and canceling, and at least a little DOM). This puts even the most basic,
style-like operations in the domain of
programmers rather than of non-programmer authors or readers. For example, collapsing sections
to a summary such as their title; selecting a column to copy, saving the current view
(rather than the original source, which with Ajax may be irrelevant), etc. There are
many simple enhancements that could improve this process, many exactly like historical
improvements in the handling of style, with similar benefits such as the greater precision
of CSS selectors.
In my opinion, we must rid ourselves of the notion that the reader is of a different
class than the author: that the Web is largely a delivery system, with complex rites
of passage to join the Guild of Authors. At present readers can fill out a form, and
sometimes add a forum comment; on Wikis they can do more. But they have no better
navigation tools than search engines and unwieldy bookmark lists. They cannot get,
on the Web, the grubby textbooks that van Dam and countless others benefit from. They
cannot share their insights with others in the context where they found them. They
cannot even make private comments on a page, that they themselves will see when they
come back. If they want upward mobility (to become
an author) they have many hoops to go through, or they must live in a walled city like a blog
At present, the Wikipedia article
First-class citizen begins
For the usage in society, see Second-class citizen. The latter in turn says:
For the usage in computer science, see First-class citizen. Can we (first-class?) denizens of Computer Science not enfranchise the society of
readers? I say, make readers first-class citizen on the Web.
[Aks88] Akscyn, Robert M., Donald L. McCracken, Elise A. Yoder. 1988.
KMS: a distributed hypermedia system for managing knowledge in organizations.
Communications of the ACM 31(7): 820-835, July 1988. doi:https://doi.org/10.1145/48511.48513. http://dl.acm.org/citation.cfm?id=48513
[Bar13] Barnet, Belinda. 2013.
Memory Machines: The Evolution of Hypertext.
London: Anthem Press. ISBN 9780857280602.
[Ber] Berners-Lee, Tim. (undated)
The WorldWideWeb browser. http://www.w3.org/People/Berners-Lee/WorldWideWeb.html
[Ber14] Berjon, Robin, Steve Faulkner, Travis Leithead, Erika Doyle Navara, Edward O'Connor,
Silvia Pfeiffer, Ian Hickson. 13 July 2014.
HTML5: A vocabulary and associated APIs for HTML and XHTML.
[Bie97] Michael Bieber, Fabio Vitali, Helen Ashman, V. Balasubramanian, Harri Oinas-Kukkonen.
Fourth Generation Hypermedia: Some Missing Links for the World Wide Web.
In International Journal of Human Computer Studies 47 (1): 31-65, July 1997. doi:https://doi.org/10.1006/ijhc.1997.0130.
[Boa14] Boardley, John. 2014.
The First Printed Page Numbers. In
I Love Typography (blog). http://ilovetypography.com/2014/02/21/the-first-printed-page-numbers/
[Bod04] Bodard, Katia, Bruno de Vuyst, Gunther Meyer. March 2004.
Deep Linking, Framing, Inlining and Extension of Copyrights: Recent Cases in Common
Law Jurisdictions. In Murdoch University Electronic Journal of Law 11(1).
[Bus80] Busa, Roberto. 1980.
The Annals of Humanities Computing: The Index Thomisticus.
Computers and the Humanities 14:83-90. doi:https://doi.org/10.1007/BF02403798.
[Bus45] Bush, Vannevar. July 1945.
As We May Think. The Atlantic.
[Cai99] Cailliau, Robert and Helen Ashman. 1999.
Hypertext in the Web - a History. ACM Computing Surveys 31(4), December 1999. doi:https://doi.org/10.1145/345966.346036. http://www.acm.org/surveys/Formatting.html
[Chi76] Chisholm, Roderick. 1976. Person and Object.
[Cle02] Clemm, G., J. Amsden,
T. Ellison, C. Kaler, J. Whitehead. March 2002.
Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning).
IETF RFC 3253. http://www.ietf.org/rfc/rfc3253.txt
[Coo87] Coombs, James H., Allen H. Renear, Steven J. DeRose. 1987.
Markup systems and the future of scholarly text processing.
Communications of the ACM 30(11): 933-947. doi:https://doi.org/10.1145/32206.32209.
[Con87a] Jeff Conklin. 1987.
Hypertext: An Introduction and Survey.
IEEE Computer 20(9), September, 1987: 17-41. doi:https://doi.org/10.1109/MC.1987.1663693.
[Con87b] Conklin, Jeff, Michael L. Begeman. 1987.
gIBIS: a hypertext tool for team design deliberation.
HYPERTEXT '87: Proceedings of the ACM conference on Hypertext: 247-251.
New York: ACM. doi:https://doi.org/10.1145/317426.317444. http://dl.acm.org/citation.cfm?id=317426.317444
[Con01] Conklin, Jeff, Albert Selvin, Simon Buckingham Shum, Maarten Sierhuis. 2001.
Facilitated hypertext for collective sensemaking: 15 years on from gIBIS.
HYPERTEXT '01: Proceedings of the 12th ACM conference on Hypertext and Hypermedia.
New York: ACM. doi:https://doi.org/10.1145/504216.504246. http://dl.acm.org/citation.cfm?id=504216.504246
[DeR89] DeRose, Steven. 1989.
Expanding the Notion of Links. In Proceedings of Hypertext '89, Pittsburgh, PA. Baltimore, MD: Association for Computing Machinery Press. doi:https://doi.org/10.1145/74224.74245.
[DeR91] DeRose, Steven. 1991.
Biblical studies and hypertext.
Hypermedia and literary studies: 185-204.
[DeR97] DeRose, Steven. 1997.
Navigation, access, and control using structured information.
American Archivist 60 (3), 298-309.
[DeR94] DeRose, Steven and David G Durand. 1994. Making Hypermedia Work: A User's Guide to HyTime. Kluwer Academic Publishers. ISBN 978-0-7923-9432-7
[DeR99] DeRose, Steven and Andries van Dam. 1999.
Document structure and markup in the FRESS hypertext system. Markup Languages: Theory Markup Lang.amp; Practice 1(1), January 1999: 7-32. doi:https://doi.org/10.1162/109966299751940814.
[DeR02] DeRose, Steven,
Eve Maler, Ron Daniel Jr. 2002.
XPointer xpointer() Scheme.
W3C Working Draft, 19 December 2002
[Dur08] Durand, David G. 2008.
Palimpsest: Change-Oriented Concurrency Control For The Support Of Collaborative Applications. Dissertation, Boston University Department of Computer Science.
[Dur96] Durand, David G., Elli Mylonas, Steven DeRose. 1996.
What Should Markup Really Be:
Applying theories of text to the design of markup systems. ALLC/ACH.
[Dus07] Dusseault, L. (ed). June 2007.
HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV). IETF RFC 4918 (obsoletes 2518). http://www.ietf.org/rfc/rfc4918.txt
[Eng73] Englebart, Douglas C., Richard W. Watson, James C. Norton. June 4–8, 1973.
The Augmented Knowledge Workshop.
Proceedings of the national computer conference and exposition (AFIPS): 9–12. doi:https://doi.org/10.1145/1499586.1499593
[Eve13] Everts, Tammy. June 5, 2013.
The average web page has almost doubled in size since 2010.
In Web Performance Today.
[Fle14] Fleishman, Glenn. Apr 15, 2014.
Papering over e-books. The Economist. Blog: Babbage: Science and technology. doi:https://doi.org/10.1145/48511.48514.
[Hal87] Halasz, Frank G. 1987. Reflections on NoteCards: Seven Issues for the Next Generation
of Hypermedia Systems.
Communications of the ACM 31(7), July 1988: 836-852. doi:https://doi.org/10.1145/507317.507328.
[Hal01] Halasz, Frank G. 2001.
Reflections on 'Seven Issues': hypertext in the era of the web. ACM Journal of Computer Documentation 25(3): 109-114. http://dl.acm.org/citation.cfm?id=507317.507328
[Inf87] InfoWorld. November 23, 1987. p. 30.
[Int86] International Organisation for Standardization. 1986.
ISO 8879:1986 Information processing — Text and office systems — Standard Generalized
Markup Language (SGML).
[Kan81] Kant, Immanuel. 1781.
Critique of Pure Reason.
Edition 2013, tr. J. M. D. Meiklejohn. "An Electronic Classics Series Publication,"
Jim Manis, series ed.
[Kan83] Kant, Immanuel. 1783.
Prolegomena to Any Future Metaphysics That Will Be Able to Present Itself as a Science. Tr. Paul Carus, 1902. http://web.mnstate.edu/gracyk/courses/phil%20306/kant_materials/prolegomena2.htm
[Koi05] Koivunen, Marja-Riitta. 2005
Annotea and Semantic Web Supported Collaboration. In 2nd Annual European Semantic Web Conference. Heraklion, Crete, May 29 – June 1, 2005. http://www.annotea.org/eswc2005/01_koivunen_final.pdf
[Mar98] Marshall, Catherine C. 1998.
Toward an ecology of hypertext annotation.
In Hypertext 98: Proceedings of the ninth ACM conference on Hypertext and hypermedia:
40-49. ISBN 0-89791-972-6. doi:https://doi.org/10.1145/276627.276632". http://dl.acm.org/citation.cfm?id=276632
[Myl01] Mylonas, Elli. 2001.
A commentary on Frank Halasz's 'Reflections on NoteCards: Seven Issues for the Next
Generation of Hypertext Systems.'
Journal of Computer Documentation (JCD) 25(3): 104-108. doi:https://doi.org/10.1145/507317.507326.
[WWW94] NCSA? 1994.
Mosaic and the web: advance proceedings: the second International WWW Conference '94. 17 through 20 1994, Chicago, IL.
[Nel87a] Nelson, Ted. 1987.
Revised edition, 1987 (original: 1974).
Bound with Nel87b. Microsoft Press: ISBN 0-914845-49-7.
Sausalito, California: Mindful Press.
[Nel87b] Nelson, Ted. 1987.
Revised edition, 1987.(original: 1974).
Bound with Nel87a. Microsoft Press: ISBN 0-914845-49-7.
Sausalito, California: Mindful Press.
[Nel81] Nelson, Ted. 1981.
Sausalito, California: Mindful Press.
[Nel99] Nelson, Theodor Holm. 1999.
Xanalogical structure, needed now more than ever: parallel documents, deep links to
content, deep versioning, and deep re-use.
In ACM Computing Surveys (CSUR) 31(4es), Dec. 1999. Article No. 33. doi:https://doi.org/10.1145/345966.346033.
[Nic95] Nicol, Gavin Thomas.
DynaWeb: Interfacing large SGML repositories and the WWW.
Proceedings of "The Web Revolution: Fourth International World Wide Web Conference.
December 11-14, 1995, Boston, Massachusetts.
[Pli] Pliny the Elder. Natural History. Preface 33.
[Rom11] Romanello, Matteo, Pasin, Michele. June 2011.
An Ontological View of Canonical Citations.
Digital Humanities 2011.
[Spe00] Sperberg-McQueen, Michael, Claus Huitfeldt, and Allen H. Renear. 2000.
Meaning and Interpretation of Markup.
In Markup Languages: Theory & Practice 2(3): 215-234. doi:https://doi.org/10.1162/109966200750363599.
[Sta81] Starr, Raymond J. 1981.
Cross-References in Roman Prose.
The American Journal of Philology 102(4), Winter, 1981: 431-437.
Baltimore: Johns Hopkins University Press.
[Str90] Strong, James. 1890.
The Exhaustive Concordance to the Bible.
NY: Abingdon Press. ISBN 0-687-40028-7.
[Tol47] Tolkien, J.R.R. 1947.
On Fairy Stories.
In C. S. Lewis, ed. Essays Presented to Charles Williams. Grand Rapids: Wm. B Eerdmans. ISBN 0-8028-1117-5.
[Uda99] Udanax.com and Project Xanadu. 1999.
A Joint Disclosure by Udanax.com and Project Xanadu as of August 23, 1999:
to accompany our presentation at the O'Reilly Open Source Conference.
[van87] van Dam, A.
Hypertext '87 Keynote Address.
Communications of the ACM 31(7), July, 1988: 887-895. doi:https://doi.org/10.1145/48511.48519. http://cs.brown.edu/memex/HT_87_Keynote_Address.html
[Vas14] Vasilogambros, Matt. May 7, 2014.
This Guy May Get Sued Over an Amazon Review.
National Journal. http://www.nationaljournal.com/tech/this-guy-may-get-sued-over-an-amazon-review-20140507
[Ven12] Venkata, Veera, Ravi Kumar Geddam, Sambasiva Rao Maddali, Devaraja Holla Vaderahobli,
Narendhar Rao Soma, Rajesh Balakrishnan, Venugopal Subbarao, Sandeep Kumar Dewangan.
Framework for supporting repair processes of aircraft.
US Patent 20120143908 A1. Also published as US8670893, US20100318396.
[Wei87] Weiss, Stephen, Mayer Schwartz. 1987. Proceedings of the ACM Conference on Hypertext and Hypermedia.. Chapel Hill, North Carolina, November 13-15, 1987.
Copyright aspects of hyperlinking and framing.
[Yan85] Yankelovich, Nicole, Norman Meyrowitz, and Andries van Dam. 1985.
Reading and Writing the Electronic Book.
IEEE Computer 18(10); 15-30. doi:https://doi.org/10.1109/MC.1985.1662710.
[Yee02] Yee, Ka-ping. 2002
CritLink: Advanced Hyperlinks Enable Public Annotation on the Web.
In Computer Supported Cooperative Work (CSCW}. http://zesty.ca/crit/yee-crit-cscw2002-demo.pdf