Footnotes on the web

I have recently been thinking about the (troublesome) state of footnotes and sidenotes on the web. Several interesting ideas have prompted me to rethink the way I use footnotes on my own website. Until today I was doing little besides the ‘standard’¹ approach normally taken by markdown parsers, but I now want to try a couple of things out in the form of a beta test.

No content changes

Whatever I did to my footnotes should not involve my going through essays and notes and changing their content. That was where I drew the line. In other words, I want to continue using the markdown approach of [^1] and [^1]: Footnote text while actually writing, and not accommodate additional markup or HTML. I find the existing markdown syntax sensible and straightforward.

Progressive enhancement

A second benefit of using the standard CommonMark format (which is also supported by most other parsers) is that I can accomplish progressive enhancement by doing nothing. So for those who turn javascript off nothing changes on this website: a footnote marker shows up with a link that will scroll you down to the relevant footnote at the bottom of an essay and a backlink will help you return to your place in the main content. So my changes are all entirely javascript-driven.

I have few complaints against this method of implementing foonotes simply because, while it may be cumbersome in comparison to doing nothing while reading, the only price it really demands is that the user click on links and scroll. This is not too bad in the grand scheme of things, but it also tells me that whatever change I bring in should not introduce interactions more complex than this.

The philosophy

I always like to understand why I am doing something before I decide how I want to do it, so my description of changes will also start with the why.

Although they are called footnotes, including semantically, talking to Pete made me realise that the manner of ‘standard’ markdown-processed footnote implementations on the web is really like endnotes in books. Footnotes are at the foot of pages, a spatial concept non-existant on individual essays, notes and blog posts on the web. And endnotes are cumbersome even in books so that is the last thing I would want.

So what is a reasonable analogy with individual pages? If one were to think of footnotes as offering additional useful information about an lemma without adding to the broader argument of the entire piece, all one normally does is—

• register mentally that a footnote exists but skip over it at first
• continue reading the sentence till the end, or even the rest of the paragraph
• either quickly glance down at the bottom of the same page or ignore the footnote entirely and continue reading

First, there are no interactions involved, only a glance. This meant my new footnote layout should not involve clicks, swipes, scrolls and such like. The sidenote-equivalents of footnotes that quite a few others implement² on the web today addresses this.

Second, if in a book they exist at the bottom of the page, they must similarly exist at the bottom of a comparable modular piece of content smaller than a page that still allows for glancing: paragraphs. They should not break the sentence itself but sit idly beneath their parent paragraph so the reader can quickly glance at them and continue reading.

This has a couple of implications: on mobile, this is exactly as I describe above. Footnotes sit beneath paragraphs allowing readers to finish a sentence or the relevant paragraph before reading the footnote, or quickly glancing down (like in a book but just below the paragraph instead of a page) before returning their eyes to the main text. On wider screens the sidenotes allow for similar glanceability without interleaving the paragraphs (see point four below). Since this layout relies on glanceability same as books, there is no question of the footnotes becoming distracting, but let us address that further now.

Third, in books footnotes are sensibly smaller than the main text (as they are on most webpages too) so they can remain distraction-free. But unless they are styled visibly differently on the web they will not allow the reader to ignore them as effectively as on books should they choose to do so. So footnotes on the web need a bit more help in this regard.

On this website I style them smaller, in a different typeface, and in a lighter tone of the main text colour. This makes them easy to ignore but also clarify their status for readers who enjoy digging into footnotes.

Fourth, unlike a single book, webpage sizes vary by design, orientation and the whims of the reader. The new footnotes would then have to lycanthropically transform into sidenotes on wider screens where they will not disturb the main text, but remain between paragraphs, elegantly spaced, so they continue to accomplish everything they ought to according to points two and three above.

Edge cases

Mobile usage is addressed according to point one above. Feed reader usage simple collapses to old-school, pure-CSS click and scroll, same as the main website used to do and continues to do for users with javascript disabled. This is especially critical since feed readers cannot be relied upon to implement alternate styles for footnotes as required by point three above. Cross-broswer compatibility was a concern while I was developing this as some offset calculations are involved in the resulting script and Chrome and Safari seemingly calculate these at different points of a document being laid out, resulting in different values and, in turn, different layouts. This has been handled gracefully.

So much for the technical edge cases. Now onto those arising out of the writing itself. I find it reasonable to expect document layout (or design if you will) concerns to accommodate for footnotes, but I find it unreasonable to expect the content to adhere to footnote layouts. In other words, if a large pullquote were to overlap with a footnote I have no automated way to prevent that. Since it is part of ‘designing’ the webpage I shall simply place the pullquote a paragraph lower to ensure no overlaps.

On the other hand, I made automated ways of preventing footnote overlaps in two edge cases: if there are multiple footnotes in a paragraph and if there are footnotes across paragraphs, or if a footnote is particularly lengthy, which causes footnotes to overlap. These occur because the content requires them and are not part of the ‘design’. Automated handling of these is therefore a necessity. See the next paragraph for an example or turn to my essay on legality and morality to see a particularly footnote-heavy essay in the wild.

Nobody should be required to plan their content based on the eventual layout of a publication so there must be an automated fallback for when we end up using³ a few footnotes⁴ close to each⁵ other, risking overlaps. In such cases the footnotes will re-flow, as you can see on the right if you are on larger tablets or desktops, or simply lie in a vertical series right below this paragraph if you are on mobile.

The outcome

Footnotes interspersing paragraphs may seem jarring due to the novelty of such an arrangement but I prefer this to having readers ‘interact’ with footnotes in any way other than their thoughts. I also think, though, that any interactions are better suited to actual eBooks (Kindle already does this, for example) where too many footnotes can make an entire book unpalatable if interspersed. But on essays here on this website, where I use a few footnotes at most, the analogy I drew above makes a lot of sense.

A fully javascript-based approach means RSS feeds will continue to see the CSS-only fallback. Or, in other words, they will see nothing different. And yet I am currently running this in beta for about a month before I settle on it permanently. (Do let me know if you spot bugs.)

There are a couple of known bugs that nevertheless do not cripple the new footnotes layout. First, while randomly ordered footnote numbers are handled perfectly by markdown parsers, something appears to be misaligning the spacing on the front end. For now this means I should ensure proper footnote number ordering while writing. Second, using any markers besides numbers⁶ causes footnotes to not get laid out in the new format which is something I should have considered when writing my code but never thought of since I only ever use numbers.

Update Both bugs noted above have been squashed. As a test, this note contains (a) footnote numbers out of order (b) randomised footnote number markers (c) footnote markers that are alphabetical and alphanumeric, not numeric alone.

Lastly, I want to reiterate that my new layout did not result from any dissatisfaction with my previous, ‘standard’ markdown layout. I still think that is the next best way to implement footnotes and that is why I retain that as a fallback. But, where they can be implemented, footnotes that allow for glanceability are the best solution.