Markdown is one of the many “light” markup conventions that came and went in recent years ([[Textile?]], AsciiDoc, WikiCreole). Markdown has seen some success based on two factors:

GitHub normalised the fact that each project’s file will get rendered prominently as Markup, if possible; on the old days the README files used to be plain text. This led to README files turning into more and more into single page documentation files with rich markup (using Markdown).

Several text editors started shipping with Markdown support (IA Writer and others). This how Markdown started to spread to other niches like book authors (specially if they didn’t want to go down the DocBook or LaTeX route).

Other niches started appearing, like Markdown versions of System Reference Documents (SRD) for role-playing games (e.g. OGL SRD5) and sites where you have an online Markdown editor integrated into a pipeline that generates material looking very close to the regular material (e.g. Homebrewery)

The original specification is vague in places and the CommonMark project attempted to rectify this situation by providing exact definitions and providing hundreds of unit tests. When you look at it this way, Markdown is definitely no longer a “light” markup system.

Many people consider Markdown to be a WikiMarkup. Indeed, it is similar visually and is supported in several wiki engines (list then maybe).

TimurIsmagilov criticizes Markdown in his gemlog post (web proxy). The main point of contention is the inability to be sure how various implementations implement the edge cases. This is a big problem if people want to use Markdown as an exchange format.

If you lower your expectations, however, and treat it as a quick and dirty markup language to be used to generate some HTML (or PDF or whatever), in a particular tool chain, then the argument of Markdown being a lousy exchange format doesn’t carry much weight. If I need to write a PDF document and I am assembling my tool chain, I most likely don’t care about the edge cases at first, it’s all Mardown to me, and when I need specific features I look up the documentation of my particular implementation just as I would be looking up the edge case of any other markup language.

Therefore, in the day-to-day use of Markdown, the fundamental weaknesses of the vague specification is never felt; the price is never paid. It’s mostly software developers that hate the vagueness, and the few that switch tool chains: – the ones that wrote a book for this platform and now they want to use a different platform. As most people expect problems when changing platforms, the problems arising because Markdown is a bad exchange format is simply subsumed in all the other problems these people have due to the change.

Counterpoint: Markdown is an exchange format already. I don’t store HTML or PDF files in those rare (really) cases I generate them. Most of the time, I often use md on GitHub. It’s not ephemeral, if you edit your old message, you’ll see md. People copy md documents from place to place. Back when MycorrhizaWiki supported md (briefly, really briefly) I imported a couple tens of md documents. Inconsistencies in parsers hit me real!



Define external redirect: Textile

EditNearLinks: GitHub DocBook LaTeX WikiMarkup