Show HN: A new way to do footnotes

All I get is a blank window in Safari.

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.

[1]: https://www.markdownguide.org/extended-syntax/

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?)

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

https://htmlpreview.github.io/?https://github.com/jgm/djot/b...

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, https://chrismorgan.info/blog/rust-ownership-the-hard-way/ 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 https://url.spec.whatwg.org/#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 [… )).