There are no true rules in reading. Apart from the visual process which we all share, everything else is utterly intimate and subjective. It can be anything from glancing, scanning, browsing, leafing, watching; some times, it's selective and non-linear, it's all about identifying keywords. Other times, it's conceptual, reflective, it's in-depth. Slow, fast, precise, functional, symbolic, social, cultural, reading is as diverse an activity as we are many.
The only rules are the limitations super-imposed by the systems we collectively design. Just think of an annotation: usually found at the bottom of the page or on the side, referencing another book or paper that you'd have to physically locate and search through. Quite a bottleneck, in terms of navigating information. The web made everything a little bit easier. It created affordances that made it easier to follow the references, but we still have to dig deep to reach what we need.
So this always raised the question: how can we harness the power of the web to make tools that allow the system to surface — rather than having to browse, explore, navigate and manage — information?
* * *
Readers are innate intellectual nomads, constantly stumbling across fields they don't own. They always seem to navigate in unanticipated directions, seeking connections that suit their own interests.
So it's no wonder that the power of text, this source of great technological breakthroughs, is in its flexibility. What's essentially nothing more than a sequence of symbols has been a vital force in our evolution.
Type, what McLuhan calledthe prototype of all machines, lead to things like the printing press, the assembly line and the internet. And it's fascinating to think about the systems that made it all possible. One of those mechanisms, typographical fixity, a linear, uniform and repeatable characteristic that allowed for the reproduction of information in unlimited quantities is something that has been — on more than one occasion — likened to how the web works.
Only when you get down to the most basic structures and think in very general terms will the patterns become clear. High-level systems, usually, have a small number of features that make it all possible. The more complex the system is, the more it can be distilled into simple, elegant, constituent functions. Basically, the vaguer the rules, the more possibilities to create, learn and evolve. In the case of HTML, I — like many others — think that one of those characteristics was the humble <a href="...">
.
The power of <a href="...">
was to turn users into makers. It allowed people — normal people who didn't have to know programming — to put things together. And it's this ability to link files together that is an important part in HTML's success story. And an inspiration for hacking the paragraph. But the ability to link text together, that could be part of HTML's future.
* * *
Reading is also writing.
We explore, we read from multiple sources, drawing selectively and critically from them, and weave together our own line of reasoning, reworking the material into constructions of our own. These sources, referenced through annotations, citations and quotations sit at the core of a vision that has generated a lot of interesting work and discussions over the years — the web as an annotation tool.
In its current form, it's a vision that Ted Nelson, the father of hypertext, strongly disagrees with. His initial vision was a system that allowed authors to include portions of existing documents into their own articles, without duplicating them. Basically, a direct reference to a piece of text (not the file) that was virtually included in the document. Or what we, today, call embedded content.
In simpler terms, it allowed users to link any piece of text to any piece of text. Again, not files, not pages, but content. Turns out that was quite an ambitious vision.
His implementation back then used normal links to which it appended an address within the document that looked something like http://documentlink.com//1942/879
. Those last digits in the link meant that the search starts with character 1942 and goes on for 879 characters. The biggest problem with that implementation is that, if you change the layout, you lose the address, you lose the text.
And here we are, 50 years later, with an elegant solution to that problem from Kevin Marks, resurfaced with the occasion of this years' W3C workshops. He calls it fragmentions and his implementation uses search links instead of cool URLs because, arguably, they're more resilient. His solution looks like http://samplelink.com/sample.html##annotate+the+web
, where ##annotate+the+web means search for the words annotate the web.
Renewed interest in the fragments problem might make things interesting. We could now — in theory at least, until browsers decide to support these features or not — link to any piece of text. But we still can't transclude. Kevin's implementation means that when you click a link, a new browser window opens and it scrolls down to the desired text.
The whole point of linking directly to a piece of text would be to reference it, quote it, cite it, or give it ampler context. Basically, to paraphrase it. To use it in that text. So why not do it in place? In the window that's currently opened, in the text you're currently reading? Why not transclude it? We have enough problems with fragmented reading as it is.
I think that the <p>
tag can do that.
The paragraph was the first idea of an annotation. It literally comes from the greek paragraphein — to write by the side — and it evolved from a note set in the margin of a paper into what we know today as a division of text to mark a change in ideas. And what are references, citations and quotations if not ideas that are trying to escape?
The paragraph is the perfect element that can be used to bring a piece of text inside another piece of text. If we start thinking of the paragraph as an annotation tool, rather than simply markdown, we can start adding attributes to it. Like the attribute that made the anchor such an important characteristic of the web: the href.
Essentially, the hack would look something like this:
<p href=http://domainname.com/address.html##annotate+the+web>
Syntax is pretty simple: ˜^^' defines the start of the quote, it ends at the expression followed by the ˜...' or at a normal sentence stop (.,!,?)
This slight recasting of Kevin's solution combined with Ted Nelson's idea of transclusions means that the browser would search for the words annotate the web and bring them in my page. Writers wouldn't have to manage sources or copy and paste content anymore. Readers wouldn't have to navigate to read.
And to get the conversation started, a good friend of mine, Radu Tizu, was kind enough to write a script that makes this happen, if you want to try it out and use it for yourself. To do that, just add this to your page:
<script src="//cdnjs.cloudflare.com/ajax/libs/jquery/2.1.0/jquery.min.js"></script&lgt;
<script src="http://escp.ro/pref/js/pref.js" type="text/javascript"></script>
<script>$(document).ready(function() {$('body').pref();});</script>
For now, due to the same origin policy, this implementation uses a jquery plugin that calls a proxy service on a server, the proxy looks into its internal cache to see if that particular reference has been previously called and used. If so, it serves the content from cache. If it's a new resource, it crawls the page, strips it down to content only, drops any formatting, puts it in the cache for later usage and serves the request. Basically, that means that if the linked content changes, the text persists as long as the cache does, after which it gets updated with the modified source text. This should work pretty well in authoring systems or even with features like Firefox/Chrome sync.
However, at a browser level, one of the biggest problems that plagued Ted Nelson's Xanadu, as well as Kevin Marks' fragments still remains: what if the linked-to text changes? Anyone can contribute to this problem by way of an Indiewebcamp wiki that Kevin put together and does a pretty good job of centralizing all the work done around this topic, as well as community discussions.
We're still figuring out how to build systems like this, but the focus of this article isn't exactly on the technicalities of it all, but rather on the interface.
If you think about it, it's not exactly hacking the <p>
as it is a natural progression of a system that already enabled so much evolution and transformation. If <a href="...">
expands the content outwards, then <p href="...">
could expand it inwards.
It's fascinating to think about the semantic structures that could arise from that. But for the <p href="...">
to turn into a semantic thing, it first has to evolve. It has to have meaningful relationships with other bits of the system or with users of the system. Imagining how that will happen is not easy. Few things are apparently obvious, like the fact that it taps directly into the linked data phenomenon. Small, direct applications in authoring tools and writing systems, such as new ways to handle quotations, citations and annotations also come to mind. This could directly effect our interfaces for linking content and our typographical systems that handle citations in new and exciting ways.
Being able to refer directly to a small piece of text is a powerful expression tool for people that work with multiple sources. It creates a world of opportunity to do things app authors don't have to pre-arrange support for. Browser-provided default behavior can bootstrap massive benefits.
Linkability for very little extra effort is also a tremendous advantage for businesses. Because it makes it easy for lots of people to refer to the same data, it also makes it interesting for search engines as a machine-readable, extractable data source.
As a practical matter, it could also operate as an augmented copy/paste tool, in the sense of the copied material also carrying its source. Who knows?
I see massive benefits at a macro scale, where the <p>
can do for HTML what typographical fixity did for text: by producing a uniformly repeatable commodity, it can be an archetype for any subsequent semantic structures.
It could make it easier to build successive iterations on the same text, from multiple sources, instead of trying to retrieve scattered fragments of a text, and thus supporting our natural, textual poaching habits. It could balance the mobility of content brought on by the <a href="...">
with some well needed immutability.
But the predictability of these systems starts at the micro scale: developers trying to communicate things to users. And one of the primary reasons people build things on the web is because they want some other people to find it, use it and make other things with it. And I think the humble <p>
can enable an ecosystem of people to do exactly that.
And maybe talking about the paragraph from this perspective will convince standards creators that the <p>
needs a href.