The March–April American Scientist has been out for a couple of weeks. My “Computing Science” column looks at the future of scientific illustration in a world where we do most of our reading not on paper but on a screen of some kind—a screen that has a computational engine behind it.

My hope for those future illustrations is that they won’t just sit on the page looking pretty. They’ll do stuff. They’ll make good use of the available computing machinery. They’ll invite the reader to interact and explore. Below is my attempt to give an example of the kind of illustration I have in mind. It’s an interactive version of the familiar population pyramid, based on data from the U.N. and built with HTML, CSS, SVG and the d3.js JavaScript library from Michael Bostock. Please play.

I’m optimistic and enthusiastic about the digital future of science publishing. The digital present is another matter. One indicator of how far we still have to go is that some of you have no idea what that population-pyramid illustration is supposed to look like, because it doesn’t appear on your screen. If you’re reading this with an older web browser, you may see a static placeholder illustration or an error message or nothing at all. If you’re reading the RSS feed, I offer my apologies, but there’s nothing I can do to help.

Apart from problems of accessibility and compatibility, there’s a deeper issue I want to address here. If the aim is to enhance the literature of science, we have to keep in mind that very little of that literature takes the form of HTML, CSS, SVG and JavaScript. Almost all journal articles and preprints are distributed as PDFs. I have no idea how to make my little animated population pyramid work inside a PDF.

“PDF” stands for Faux Paper Document. PDFs look just like their printed prototypes, with all the typographical niceties—justification, hyphenation, kerning of letter pairs, ligatures. It’s as if the words and pictures had been skimmed off the page and pasted onto the screen (which is in fact pretty close to how the process works). This fidelity to the print tradition follows directly from the history of PDF: It was an outgrowth of PostScript, which was an outgrowth of InterPress, which was developed as software for use in the printing trades. The successful imitation of paper documents is a laudable achievement. As a culture, we have several hundred years of effort invested in learning how to present information effectively and attractively on the printed page; we shouldn’t let that go to waste. However, using a multigigahertz, multigigabyte computing machine as a standin for a sheet of dried cellulose seems a bit of a waste. It’s rather like early printers striving to reproduce the stylistic quirks of scribes writing with quill pens.

HTML can’t match the designerly refinement of PDF, but it is more versatile, livelier, and even playful. HTML documents do tricks. Where PDF is for the suits, HTML/CSS/JavaScript is the home of hackers.

But, again, few scholarly papers are published in HTML. There are a number of reasons for this, but to me the one that seems most salient is a certain lack of thinginess. In my column I write:

Why do authors and readers prefer PDFs for this kind of publication? One factor may be this: A PDF is something you possess. You download it from a server, give it a name, store it in a folder. It’s yours; it stays put. A website built out of HTML has a different character. It’s not a thing you own but a place you visit. You can’t take it home with you—although perhaps you can send a postcard or keep a small souvenir in the form of a bookmark.

“HTML” is an abbreviation for Highly Temporary Markup Language.

If we take this view seriously, then what the world needs is a way to encapsulate HTML documents so that they become first-class, discrete objects—things you can keep, rename, pass around, copy, delete, annotate, modify. For years I thought that this capability should be built into web browsers—that you should be able to press a button to download and store a fully functional and totally self-contained local copy of any web page. My favorite browser of the 1990s, called iCab, came pretty close to this ideal, but for many modern web pages the client-side approach is either unworkable or undesirable. With pages that rely on technologies such as AJAX, it’s not possible to make a fully self-sufficient local copy. And often there are page elements you don’t really want to include in your private copy, such as navigational menus and “Like” buttons and comment forms.

An alternative strategy is to let the author of the HTML document take responsibility for creating a downloadable, autonomous version, with content tailored for that environment. A technology for doing this sort of thing already exists: It’s the EPUB format used by various eBook readers. An EPUB document is essentially a collection of HTML files, CSS stylesheets and various forms of metadata wrapped up in a zip archive. SVG is supported, along with MathML. The 3.0 standard says JavaScript is also acceptable, but that statement is accompanied by a list of warnings that sound like the side-effect disclosures in a pharmaceutical ad.

Apple’s new iBooks Author program also produces some kind of encapsulated HTML, but of course it works only in the Apple sector of the universe. If you’d rather affiliate with a different proprietary dominion, there’s something called CDF from Wolfram Research. (The initials stand for “Conrad’s Document Format.”)

Still another approach would be to stick with PDF but make it more fun. According to the PDF 1.7 specification (which, as you might guess, comes in the form of a PDF), a JavaScript compiler is supposed to be available within PDF documents, and Adobe has an Acrobat JavaScript API document. But as far as I can tell scripting is commonly used only for validating forms and playing slideshows.

The latest version of Acrobat does have a pretty cool interactive viewer for three-dimensional objects. Three years ago Alyssa Goodman and her colleagues at Harvard published a paper in Nature that made use of that viewer. This was apparently the first scientific publication to include a 3D PDF. I don’t know of another example since. And I have never seen any other kind of interactive graphics embedded in a PDF.

For more on all this, I invite you to read my column in the format of your choice: good old-fashioned paper, fine artisanal HTML (with whiz-bang JavaScript graphics), or the pixelated form of paper we call PDF.

This just in from Bill Gasarch: The quest for a rectangle-free four-coloring of the 17-by-17 grid is over. If you don’t know what that’s all about, and you’d like to find out, see Bill’s blog post from 2009 or my earlier comments (one, two, three).

The coloring above (along with several others) was found by Bernd Steinbach of Frieburg University and Christian Posthoff of the University of the West Indies. They win the $289 prize that Gasarch had offered for a solution.

Gasarch has posted more details on the Computational Complexity blog. But apparently we’re going to have to wait until May to learn how the coloring was found. The one interesting clue revealed so far is that the paper will be presented at the International Symposia on Multiple-Valued Logic.

Addendum 2012-02-11: For the benefit of those who don’t read the comments, I repeat a remark from reader Craig:

What I don’t like about this solution (or, indeed, the solutions to other related problems) is the arbitrariness. Is it not the case that you should be able to permute the rows and columns of any solution and arrive at a new solution? That being the case, I feel that you should be able to adjust the rows and columns here in order to highlight some kind of revealing pattern in the colouring.

Indeed, the matrix of dots shown above is one of (17!)² equivalent solutions. How should we choose one of those permutations to serve as a representative of the class?

Personally, I’m not optimistic about finding a “revealing pattern” in any of the 126513546505547170185216000000 permuted matrices. If there were some simple, concisely described rule governing the arrangement of the dots—other than the no-monochrome-rectangle criterion itself—then we could make use of that rule to find a solution, or at least to reduce the search space. When Steinbach and Posthoff reveal their secret method, maybe we’ll learn that such a rule exists, but I doubt it.

Even if we can’t make a pretty picture by permuting rows and columns, it would still be useful to have some canonical ordering, so that we could easily determine whether two arrays are members of the same equivalence class. I’m not sure how best to do that, but if we assign an ordering to the colors, we can at least sort them.

There is still some arbitrariness here. We have not dealt with the 4! orderings of the colors. Is there a smarter way to go about it?

Imagine, if you will, the year 2020, when a billion people around the planet are at their screens. And each is able to withdraw from a great repository any fragments of anything that has been published, as well as the private documents he or she has access to. So, you’re able to bring to your screen not just encyclopedias, not just novels, not just the works of Horace and Cicero and Marcus Aurelius and Shakespeare and Goethe, but obscure stuff from South America and Africa that people have written in the last 5 minutes. And [you're able] to make comments and footnotes and to transclude and quote from anything else that’s published, with automatic royalty.

That’s Ted Nelson, the prophet of hypertext, writing in Byte in 1990. We still have a few years to go before 2020, and yet almost everything Nelson foresaw is already upon us. More than two billion people around the world are sitting at their screens. The encyclopedias and novels are online, along with Horace, Cicero and the rest. Twitter will show you what’s been written in South America and Africa in the last five minutes. For commenting, transcluding and quoting, we have Facebook and many other thriving channels of commerce and communication (even blogs like this one). So what remains to be invented before we arrive in Nelson’s stately pleasure dome of Xanadu? Well, “automatic royalty” hasn’t shown up yet. More surprising—and more annoying—we still don’t have footnotes on the web.

It’s a worrisome lack. How are scholars to annotate and document—not to mention digress and distract—without footnotes or some similar device? In a recent essay Alexandra Horowitz cites Edward Gibbon, J. L. Austin, Nicholson Baker and David Foster Wallace as authors whose work would be diminished or even destroyed if stripped of notes. I would add Vladimir Nabokov to the list, for his novel-in-notes Pale Fire. Martin Gardner deserves mention as well—not for his columns in Scientific American, where footnotes and marginalia were sadly forbidden, but for his annotated editions of Lewis Carroll and others. And the most important example of all is the Talmud, the archetypal hypertext of modern times. We should be able to do stuff like that that in HTML!

Why are footnotes not a standard feature of web life? Perhaps because the founders believed that the central mechanism of the web—the anchor tag <a href= … >—adequately served the purpose. And people do use <a> tags for notes. For example, there’s the Wikipedia protocol, where clicking on a footnote link^[1] sends you on a trip to the bottom of the page, where you’ll find a helpful caret to take you back where you came from. This scheme does a good job of mimicking the ink-on-paper experience of footnotes—and ignores all the capabilities and possibilities of a new medium.

Back in 1995, the HTML 3.0 proposal included a <fn> tag for footnotes. But HTML 3.0 was stillborn, and the 3.2 version that replaced it a few months later dropped footnote support (and much else). HTML5 now offers the <aside> tag, which sounds like it ought to be the semantically correct way to mark up footnotes. But I have yet to see any website in the wild actually using <aside> that way. And the (still tentative) HTML5 standard suggests that footnotes were not the the original intent of the tag:

The aside element … can be used for typographical effects like pull quotes or sidebars, for advertising, for groups of nav elements, and for other content that is considered separate from the main content of the page.

It’s not appropriate to use the aside element just for parentheticals, since those are part of the main flow of the document.

Yeah, whatever. But what makes the web such a grand playground is that you can always build your own tools and toys if you don’t like the standard kit. Which brings me to all those blue links with dotted underscores in the paragraphs above. I assume you’ve tried them out by now. The device is called a knowl, and I discovered it the other day while browsing on the home page of the American Institute of Mathematics in Palo Alto. The knowl’s inventor is Harald Schilly of the University of Vienna.

It’s all done with a dab of jQuery and a dollop of CSS. The markup in the HTML file is just a mutant anchor tag:

<a knowl="wikitag.html">Wikipedia protocol</a>

where the normal “href” has been replaced by “knowl.” The jQuery code installs an onClick handler for each instance of this structure found in the text; the onClick function calls out to the server, loads the content of the note, and adds that text to the document tree as a sibling of the current node. CSS rules add a bit of border styling. The little drawer-like pane opens just below the current paragraph (or whatever other HTML element contains the reference to the knowl).

The knowl is not quite everything I would wish for in a footnote utility. A minor issue is that the “next-sibling” rule for placing the text of the knowl doesn’t always do the right thing. A less-minor issue is that the authoring process is overly arduous. Every knowl goes into a separate file, so writing the text requires a change of mental focus and also creates a lot of file-system clutter. I’d rather include the text of the note at the point of reference (the way it’s done in LaTeX, say). That could be accomplished with an easy change to the JavaScript. On the other hand, the system’s reliance on JavaScript is in itself problematic. The world of knowls is off-limits to those who write on hosted platforms such as WordPress.com or Blogger, because they forbid JavaScript in posts. I wonder if the same visual effects could be achieved entirely with CSS3 animations?

When Schilly and his colleagues at AIM developed the knowl, their goal was not to satisfy my footnote fetish. As a matter of fact, they seem to have a rather different vision of how knowls might be used—not as a medium for the Shandean digressions of self-indulgent writers like me but as shared nuggets of wisdom, offered as a public resource. David Farmer, director of programs at AIM, writes: “I envision a time when the Internet has a repository of such knowls, reliable and ready to be referenced anywhere.”

Unfortunately, there’s a technical impediment to making that vision a reality. When I started writing this post, I thought it would be only appropriate to transclude the definition of transclusion that’s given in one of the knowls above. So I constructed a knowl linking to the file on aimath.org where that text exists. This knowl has such a link. If you click it, you’ll find that it doesn’t work: The little blue drawer slides open, but it is empty. The reason is that the page you are reading now was downloaded from bit-player.org, but when you click that knowl, it tries to access HTML content from aimath.org; that attempt runs afoul of the browser’s “same-origin policy.” There are ways of evading this security provision, but they come with a faint scent of hackery. Without them, though, I don’t think we can have our public repository of knowls. It looks like we’ll each have to serve up our own wit and drollery.

Update 2012-02-28: Harald Schilly has shown me that transclusion is not a vain dream after all. The solution relies on a fairly recent technology called Access Control for Cross-Site Requests, and it requires a cooperating server to set an appropriate flag in an HTTP header. This knowl is fetched from appspot.com, the hosting arm of the Google App Engine, which allows cross-site connections from anywhere. If you are reading this page with a recent Webkit browser (Google Chrome, Safari) or a recent Mozilla browser (Firebox), the magic drawer should open with a note inside. But Opera does not implement the method, and I think Internet Explorer is also a holdout, although I don’t have the means to check. I was totally unaware of this trick, and I’m grateful to Schilly for enlightening me.

^ Hi! I’m a Wikipedia-style footnote. I feel lonely and exposed and painfully out of context down here.