John Gruber recently wrote about footnotes on web pages, the challenges they present, and how he deals with the issue. He comes to the conclusion that when wanting to display footnotes at the bottom of the page you should provide a back-reference with the footnote text, so your readers can find their way back to where the footnote mark is.
This has two advantages. One being that it’s quite handy to be directed right back to where you came from. And the other being that it’s technically simple – requiring nothing but standard HTML.
And you know what? – I hate them. Those notes just suck. Not only because footnotes themselves aren’t the prettiest or most useful things to find in a text. But because having to click and jump around in the web page to read them is a pain. And because clicking the back link won’t return the web page to the state you had it in before jumping to the footnote’s text but to a state where the footnote’s mark will be at the very top of the web browser’s content area. Which means you can’t just continue reading where you left off before jumping to the footnote.
So we’re having at least problems here. One being the technical one that we won’t jump back to the correct place and the other being the inconvenience of all the navigation that’s needed for going to the footnotes and back.
And looking at the technical problem, you’ll see a rather simple solution: The browser’s back button. Hitting your browser’s back button will return you to the exact place on the page where you clicked the link to the footnote. And this, unfortunately, implies that having the ‘back’ arrow link at the end of footnote may be a disadvantage for the readers – i.e. people reading the text front to back rather than wildly ‘surfing’ through the text – as they’ll be tempted to click it rather than using the browser’s back button which would give a better result.
Perhaps some clever scripting could be used to determine whether or not it will be better to use the browser’s back command or the fixed link to return to the foonote mark. But I doubt that you’ll be able to get reliable results with that. And it’d ruin the simplicity of John’s solution which has the added advantage of creating a proper link between the footnote’s mark and its text.
Which of course wakes up my inner LaTeX geek, and forces me to point out that reasonably good footnote handling should just let the footnote’s text be entered at the same place where its mark is, making both the editing and the structure of the text easy to handle and understand. But HTML may not be powerful enough for that.
The other problem I saw was one of convenience. Thinking about it, it may be more a conceptual problem, though. While footnotes may not be particularly nice, they are nowhere as bad as John’s web footnotes. And after seeing all the navigation trouble you have to go through it becomes apparent that these shouldn’t be called footnotes at all as they are endnotes, i.e. notes which are made at the end of the section or article rather than notes made at the bottom of what you can see. And if you ever had to read a printed article using endnotes instead of proper footnotes, you’ll probably have cursed the publisher for doing that and been tempted to stop reading the endnotes at all.
And I think that’s the reason why what started off with what looks like a well thought-out plan by John doesn’t give good results. A web page is different from a paper page. It’s more like a section in a book than it is like a physical page. And thus, John’s footnotes aren’t footnotes but endnotes.
If you found all the interesting, be sure to also read John’s follow-up which contains additional remarks on notes in web pages and answers some remarks by Joe Clark. Joe has a nice site using Zapfino and featuring many photos of fonts in the wild. And he also remarks that there are no proper footnotes in HTML. But he probably goes a little too far in criticising John’s ↩ arrow to return from the end of footnotes and suggesting to use ↑ instead.
I’m all for Unicode, but I am not quite sure how slavishly we should read its character names. While it’s not written explicitly in the Unicode files, the ↩ arrow is the Unicode character whose looks come closest to the arrow I find on the ‘return’ key of the keyboards that don’t have the word spelled out on them. (Although there still is ↵ which seems to be a closer correspondence technically but looks different.)
And even with all these arrows around, I find it hard to really care. Each of them will do the job for me. Whom will it make a difference for? If screen readers slavishly read Unicode names, John’s solution might be annoying as having
leftwards arrow with hook read out is more annoying than it is poetry. But at least for Apple’s VoiceOver, the character’s name will be read as – surprise!, and I am really surprised here as I just tried this for the heck of it –
return. I suppose this worked correctly because Apple use that very arrow to indicate the return key in their own applications and thus included it in VoiceOver for correct pronunciation – while the ↵ arrow I mentioned above will just be read with its Unicode number. So at least for his own site, which is somewhat Mac centric, John could even win this argument that nobody cares for.
Received data seems to be invalid. The wanted file does probably not exist or the guys at last.fm changed something.