Testing… The editor always shows something different from what gets rendered in the topic thread
markdown: [^note] + [^note]: This is supposed to be a footnote..
In a test post over at discourse.python.org, placing the caret inside OR outside the square brackets both produce an inline note
markdown: ^[this is coded as an inline note].
…and the same thing happens here. It looks great in the editor’s Preview Pane, but doesn’t render as expected in the thread. (Although the hyperlinks are also very dark and small in the Dark Theme currently active at discourse.python.org.)
I think I’m going to use folding dropdowns <1>.
Because I can put them immediately after the paragraph that relates to the extra info–and they might, when collapsed, even take up fewer lines than a long footnote would. (Tried to use square brackets around the ‘1’ but couldn’t figure out how to escape the square brackets to keep them from confusing the markdown interpreter.)
We’re struggling with this at
These options for supplemental notation can enhance the deep richness of Discourse. There are some keys to a successful implementation, though.
The main departure from ideal is using the term ‘footnote’ for something that patently is something else. An inline note is inline whereas a footnote is at the foot/bottom of the page (in our case, the foot of the message).
And that highlights the second departure: footnotes and inline notes are two distinctly different types of note with ostensibly different use cases and different best practices for their effective use. Therefore, they should be separate features and probably controlled by separate sets of config variables.
Through the option of changing the caret location, the user can decide whether to use an in situ expansion (inline note) or a remote reference (footnote). Right now, both constructions produce an inline note. We’ve found this a bit baffling, though it is useful to place bulky note text at the bottom of a message rather than having it interlope onto the body text in the composition editor.
At any rate, we at
discuss.python.org would very much like to be able to use both inline notes and footnotes. It would extend the engaging nature of a well-composed topic post.
One option is to have the caret’s location be two different switches:
^[txt] to make an inline note.
[^lbl] to make a footnote.
^[^lbl] to make an inline note with the note text located remotely from it’s display location.
A common name for these two supplemental text items is ‘Annotations’.
I think this would probably be best first resolved as part of the CommonMark spec. See How should footnotes behave? - Extensions - CommonMark Discussion as linked above.
Agreed, Matthew. And thank you for highlighting the references. Unfortunately, those references are a bit light and I found no better topics here. Maybe CommonMark.org has more recent discussion.
Resolved, yes. I first need to work out what and how to present the situation to CommonMark, though. I posted here since other user input will inform the discussion when the topic is forwarded to CommonMark. Discourse is also our immediate “parent” as users and Sam et al will probably want to know how well the extension implementation of footnotes is working for its users.
So please share your thoughts–and make it fast because there’s a ‘garbage disposal’ on this topic that eats posts after 30 days!