Standard reminder that Markdown, while having no formal standard, tends to be implemented in broadly compatible ways across various systems. Yes, there are edge cases -- yes, I've seen the lists comparing different renderers; yes, I've run into differences once in a while myself -- but in general, it turns out that the Markdown documents I wrote 15 years ago are still perfectly readable today, no matter what Markdown engine I drop them into. Or, you know, even if I don't drop them into a Markdown engine, because the entire point of Markdown is to be easily human-readable, without "looking like code," before rendering in the first place.

Markdown isn't the be-all and end-all of markup formats, and there are valid reasons for using formats with strict specifications (e.g., AsciiDoc or ReStructuredText for certain kinds of technical writing). But the chances of Markdown documents suddenly being woefully unreadable in 20 years are roughly in line with the chances of plain text Unicode documents being unreadable in 20 years.

Commonmark is a wonderful and well defined markdown standard (ie the one GitHub uses)

I’m not sure that GitHub uses CommonMark! Generally GitHub's format is referred to as GFM (GitHub-Flavored Markdown) and it has notable differences including preserving newlines.

Notably, GitHubbers and StackOverflow representatives joined to define CommonMark, but GitHub and StackOverflow do not have remotely similar fenced code block conventions.

Also, CommonMark currently says that they have not yet defined a version 1.0 of the spec.

I certainly applaud the effort, but CommonMark did not unify all the Markdowns.

Cited in the spirit of good humor, but not irrelevant: https://xkcd.com/927/

Serious question - how is it not irrelevant? Should it be posted any time people discuss the pros and cons of various standards?

To be fair, this is exactly what happened, since CommonMark did not cause all Markdown users and implementors to converge.

Markdown is thirteen years old. This is older than HTML5, which introduced '<article>', '<section>', '<header>', '<footer>', '<figure>', and '<aside>'; and it's older than lots of modern CSS features. I've got archives in a variety of markup languages going back several decades; I've found old Markup easier to work with than old HTML or SGML. YMMV, though.

If your documents are available on the open web, you can visit them on the Wayback Machine to make sure they're cached as HTML. This is in some ways more reliable, and some ways less, than trying to keep track of your own HTML transcodes over decades. It's generally a more reliable way of making sure they're available after you disappear.

As a daily user of org mode for notes, agenda, todo lists and word-processing (I LOVE IT) I'd recommend against using it for sth. like a blog. I did try. First of all it's a moving target, new syntax is introduced not-infrequently. Then, the API is cumbersome at times, and it's also slow. My org-publish setup with an RSS exporting function bolted on took many tens of seconds to export, even when only a single file was modified. I migrated to Textile for my website. It's implementations are all compatible, and it's way more comprehensive than any version of markdown.

Markdown is IMO good enough to archive.

The major point of using markdown, or why I use it, is that it doesn't require a working implementation to be understood. I can open a markdown file in ed and still understand it. From what I've seen of RestructuredText and Org-mode, if i'm not using the implementation, it becomes a mess.

(I also always recommend to put anything that isn't widely implemented in Markdown in HTML instead since that will be reasonably parsable for the next couple decades.)

org-mode is even less standard than markdown. The one and only editor for it is emacs. I haven't seen another implementation that is even close to complete.