Show HN: A new way to do footnotes

22 points6
verdagon45 minutes ago

Anyone interested in footnotes might like the way we do it on the Vale site, for example:

Some nice things:

* The footnotes are off to the side, so it's closer to the text that mentions it and it doesn't interrupt the flow of the main text.

* It uses colors, so it's pretty fast to visually jump to the right one.

* We keep the numbers too, for colorblind folks (and those using blue-light filters like f.lux)

* It works without javascript!

Our markdown->html renderer makes this happen by slicing up the page horizontally, one slice per header. Each slice then has a wide left column for the main text, and a narrow right column for the footnotes. Then if the user happens have javascript enabled, it position:absolute's the footnotes and lines them up a little more precisely with where they're mentioned.

woodruffw3 hours ago

At the risk of Dropboxing myself: what is the advantage of this over the existing Markdown syntax for footnotes[1]? It looks very similar, but with a harder to parse grammar.


SPBS3 hours ago

it looks like it aggregates all footnote definitions into one where it can be printed with the keyword 'notes' (hardcoding? too clever? what if you want to separate footnotes?)

reagle3 hours ago

I can’t see what this offers over pandoc markdown or it’s successor:

pbronez2 hours ago

Shot is new to me, thanks for sharing. Looks like a nice iteration on CommonMark. I’ve preferred Asciidoc for its availability to handle complex nested headers and internal links; djot’s custom attributes and local-first link parsing might handle that well.

tux3 hours ago

WOW I didn't even know markdown has footnotes will definantly come in handy for one of my projects. Thank you!

bmacho3 hours ago

It doesn't have footnotes. Some supersets do.

woodruffw2 hours ago

Right, but it's worth noting that those supersets are very common. I'd say it's actually less common to run into a "barebones" Markdown implementation these days than to run into a GFM or close-to-GFM one.

iprathik53 minutes ago

Clicking on the number should ideal take me to footnote but it isn't. Instead its redirecting to a different page taking about scroll

sillysaurusx3 hours ago

I like the URL syntax. It's a clean separation between typing a sentence and attaching a link within that sentence. Nicely done.

chrstphrknwtn4 hours ago

All I get is a blank window in Safari.

macintux4 hours ago

Works on my iPad. Any JS restrictions in your browser?

chrstphrknwtn1 hour ago

Nope, just JS errors

[Error] SyntaxError: Unexpected token '='. Expected an opening '(' before a method's parameter list. (anonymous function) (libs.js:16558)

[Error] ReferenceError: Can't find variable: AbstractTreeComponent Global Code (app.js:4)

[Error] ReferenceError: Cannot access uninitialized variable. (anonymous function) (

chrismorgan2 hours ago

I’ve been designing a lightweight markup language of my own in recent months, and yesterday I finally settled on a syntax that I like for notes: links (which must always be delimited in my language), but with a leading caret, which will never be present in properly-serialised URLs. (The URL ^x should be encoded %5Ex—the URL parser will accept the caret, but it’s marked as invalid if anyone cares, and the serialiser would turn it into %5E.)

This makes perfect sense, because notes semantically really are links from one piece of content to another.

My URLs must always be delimited in angle brackets <…>, and links can be either <url> or [contents <url>]. (I haven’t settled on a syntax I like for reference-style links.) This fits in very nicely with caret starting note references. You can have [spanned notes <^…>] and spanless notes<^…>. (I also reckon on the identifier being optional, so that <^> would be valid, just using the next note body.) This syntax is generically useful for sidenotes, footnotes, endnotes and other presentations of notes—in general, I reckon note presentation should be a presentational rather than a content concern.

(Aside: what people on the web call “footnotes” are almost always actually endnotes. Endnotes are typically ergonomically poor in both print and screen media. Something along the lines of proper footnotes or inline-expandable notes mostly requires JavaScript, though with effort, restrictions about whether the content can contain blocks, and perhaps careful tip-toeing around HTML parser implementation details (or deliberately using XML syntax if you’re bold enough) and a mild disregard for nominal validity, you can do it even semantically reasonably without JavaScript.)

I reckon most notes should be spanned. To demonstrate what I mean, shows three types of sidenotes: spanned with an inline source marker, unspanned with an inline source marker, and full block asides which are unspanned. To see my vision most clearly you’ll need a large enough viewport; on small viewports, I currently have the notes inline, with the third type aside, and I’m not happy with the in-flow placement of the asides, which is mostly a paragraph or so above the ideal place, but wanted it to all be pure CSS.

Then I started wondering, how many potentially viable characters are there like this, that can’t appear at the start of properly-serialised URLs? Could they be purpose for something else? You start with all Unicode scalar values, then remove (a) all URL code points <>, because they’re valid in URLs; (b) C0 and C1 control codes because non-printables is an extremely terrible idea for normal people; (c) `#`, as it’s used to begin fragments; (d) `%`, as it’s used for percent-encoding bytes. This leaves: "<>[\]^`{|} and space. Most of them would be a bad idea for various reasons, even if they’d work; ^ and | are the only two that seem reasonable to me.

So, ^ for notes. Haven’t thought of anything that fits similarly that pipe could certainly be used for. Could possibly use it for reference-style links, but that’d still be clunky (I would like to support […] matching, not needing [… <|refname>)).