In recent posts I’ve used ASCII footnotes like "^1" to indicate more information about a subject in a footnote line starting with "^1" at the bottom of the post. Both inline refs & footer notes should use Unicode superscripts like '¹' and hyperlink both ways, in contexts that support it. I have heard feedback from the #IndieWeb community that inline ASCII footnotes like "^1" are distracting and interrupt the flow of reading, and I can sympathize with that. From an authoring perspective, it’s easier to type "^2" than "²" so I’d rather keep doing so, and write code to do the conversion. I’m also considering what to change as an author, like instead of footnoting special terms/jargon, I can include them in an mini-glossary at the end of a post, thus only using footnotes for specific points or citations. I won’t include terms that mean exactly the same thing as defined by a literal page of the same name on Wikipedia (e.g. ASCII in this post means https://enwp.org/ASCII). During a run I figured out how my existing CASSIS autolink function could detect both inline footnote references and their expansions, convert them to Unicode, and add local hyperlinks in both directions, given an optional parameter to prefix their fragment IDs. I looked at Wikipedia’s references and fragments for examples, and they use "_ref-{number}" and "_note-{number}" respectively which seem sensible. The one Wikipedia design aspect I disagree with is their use of a hat character '^' at the *start* of a reference note to link back to the inline reference, which look distracting, and in my opinion are too subtle/unobvious. I prefer what I’ve seen on blogs: a small return arrow '⮐' at the *end* of a note to link back to the inline reference, which does a much better job of conveying the meaning of “return to where this was referenced / you were reading.” Lastly, I think it’s ok if POSSE copies of my posts to text-only (non-hyperlinking) destinations keep the ASCII footnote style, because such copies usually (e.g. on Twitter) lack enough space for the expansions, and there is less chance of ASCII footnotes being misunderstood as part of something else on those destinations. POSSE destinations are in general lower fidelity than a personal site, so it’s ok have this be another instance where the original looks better than the copy. I collected many of these thoughts in a brainstorming section on the IndieWeb wiki accordingly, and will update that as I make progress: https://indieweb.org/footnote#Brainstorming If you use footnotes in your personal site posts, please add yourself to the IndieWeb Examples section: https://indieweb.org/footnote#IndieWeb_Examples This is day 28 of #100DaysOfIndieWeb #100Days ← Day 27: https://tantek.com/2023/033/t1/twitter-api-log-in-web-sign-in-relmeauth → Day 29: https://tantek.com/2023/037/t1/post-glossary Post Glossary: autolink https://indieweb.org/autolink CASSIS https://indieweb.org/CASSIS POSSE https://indieweb.org/POSSE Unicode superscripts https://en.wikipedia.org/wiki/Superscripts_and_Subscripts_(Unicode_block)

In recent posts I’ve used ASCII footnotes like "^1" to indicate more information about a subject in a footnote line starting with "^1" at the bottom of the post.

Both inline refs & footer notes should use Unicode superscripts like '¹' and hyperlink both ways, in contexts that support it.

I have heard feedback from the #IndieWeb community that inline ASCII footnotes like "^1" are distracting and interrupt the flow of reading, and I can sympathize with that.

From an authoring perspective, it’s easier to type "^2" than "²" so I’d rather keep doing so, and write code to do the conversion.

I’m also considering what to change as an author, like instead of footnoting special terms/jargon, I can include them in an mini-glossary at the end of a post, thus only using footnotes for specific points or citations. I won’t include terms that mean exactly the same thing as defined by a literal page of the same name on Wikipedia (e.g. ASCII in this post means https://enwp.org/ASCII).

During a run I figured out how my existing CASSIS autolink function could detect both inline footnote references and their expansions, convert them to Unicode, and add local hyperlinks in both directions, given an optional parameter to prefix their fragment IDs. I looked at Wikipedia’s references and fragments for examples, and they use "_ref-{number}" and "_note-{number}" respectively which seem sensible.

The one Wikipedia design aspect I disagree with is their use of a hat character '^' at the *start* of a reference note to link back to the inline reference, which look distracting, and in my opinion are too subtle/unobvious. I prefer what I’ve seen on blogs: a small return arrow '⮐' at the *end* of a note to link back to the inline reference, which does a much better job of conveying the meaning of “return to where this was referenced / you were reading.”

Lastly, I think it’s ok if POSSE copies of my posts to text-only (non-hyperlinking) destinations keep the ASCII footnote style, because such copies usually (e.g. on Twitter) lack enough space for the expansions, and there is less chance of ASCII footnotes being misunderstood as part of something else on those destinations. POSSE destinations are in general lower fidelity than a personal site, so it’s ok have this be another instance where the original looks better than the copy.

I collected many of these thoughts in a brainstorming section on the IndieWeb wiki accordingly, and will update that as I make progress:

https://indieweb.org/footnote#Brainstorming

If you use footnotes in your personal site posts, please add yourself to the IndieWeb Examples section:

https://indieweb.org/footnote#IndieWeb_Examples

This is day 28 of #100DaysOfIndieWeb #100Days

← Day 27: https://tantek.com/2023/033/t1/twitter-api-log-in-web-sign-in-relmeauth
→ Day 29: https://tantek.com/2023/037/t1/post-glossary

Post Glossary:

autolink
https://indieweb.org/autolink
CASSIS
https://indieweb.org/CASSIS
POSSE
https://indieweb.org/POSSE
Unicode superscripts
https://en.wikipedia.org/wiki/Superscripts_and_Subscripts_(Unicode_block)