Balisage Paper: What do we still lack?

Introduction

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.^[2]

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 and writers.

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 technology because the last one only almost gets you to your goal. HTML, CSS, Javascript, event models, AJAX, DOM, WebDAV, Apache, 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:

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:

How was hypertext possible (before the Web)?

Of course, hypertext as we usually think of it uses computers to take the reader from one 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 it could.

In such acts the reader becomes something more — but what, exactly? Possibly a reader who merely 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:

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 sell downstream.

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 even the 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:

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 example (Spe00).

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 one views 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 era.

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

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:

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 or tools.

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:

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:

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.

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):

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 it, unless they are quite fluent in Javascript, DOM, CSS, HTML, and several other technologies. Should a reader master all those, few of the skills transfer to common authoring environments (for example, customizing OpenOffice requires different languages and radically different APIs from handling DOM via Javascript).

What could readers do in a better world, that they basically cannot now?

Dynamic (rule-based or implicit) linking

DeR89 discussed the division of links into explicit vs. 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 effect).

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 systems.

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, expert vs. 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).

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 the reader.

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, and many kinds of horizontal layout needs can only be done with special Javascript, 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 use not only CSS, but also Javascript. Interaction requires programming skills and tradeoffs: attaching onXXX attributes which are at least as anomalous in HTML as the long-deprecated hard-coding of style properties; or attaching them via Javascript (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 site.

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.