Oh I'm not brave enough for politics.

You compile your markdown and don't read it raw? /s

GitLab/Hub obviously. Also it doesn't matter since I don't need to compile it to read it.

I think the best way to go about this would be adopting the CommonMark standard but adding/changing a couple things to really complete it:

• anchors/heading identifiers

  • Creating a heading with a custom identifier:

  • Creating an anchor/heading identifier (clicking a link to an anchor would navigate the user to whatever block/paragraph contained the anchor):

    ## the name of my heading {#header-id}
    
    {#a-paragraph} Blah blah blah blah.
    
    {#list}
    - blah
    - blah
    - blah
    

  • Linking to an anchor/heading:

    Here's [a link](#list) to my list in my ["the name of my heading"](#header-id) section.
    

• footnotes

  • Note: The part in brackets is the reference. The part at the bottom is the reference definition.

  • But we should have it so that if the reference definition is just a link, it's treated as a link reference and presents as a normal link, but otherwise it's treated like a citation and just navigates you to the reference definition.

  • Example:

    I learned about blank[^footnote] after i saw someone mention it on [Lemmy].`
    
    [Lemmy]: https://join-lemmy.org/
    
    [^footnote]: Author's name, Date accessed. Title. https://www.example.com/.
    

• tables

• in-line strikethrough

• superscript

  • But something less ambiguous than normal^super is needed (notice how, normally, the notation for all in-line formatting is surrounding text with some special character(s)). Something like normal^super^ may be better.

• subscript

  • Again, we should probably come up with something less ambiguous than normal_sub. Maybe something like normal_sub_? And yes, i know _text_ is sometimes used for italics instead of *text*, but that's something that just needs to stop honestly.