
Why Markdown sucks - ash
http://joearms.github.com/2016/03/21/Why-Markdown-Sucks.html
======
makecheck
Individual sites/sub-sites should definitely have the option of locking down
or at least specifying the engine that they depend on. (In the case of the
latter, in theory GitHub could collect the “in use” specifications of all
projects and get some idea who needs what before making a change.)

Ultimately though, if you need control then you have to _take_ control.

I have been using "textile" for the help documentation in my project for
years. I simply copied the entire Python rendering code into my project.
Nothing can break until I am ready to change (and I rarely find new versions
of the rendering engine anyway).

------
WorldMaker
I carried the banner for reStructuredText for a while in the "text markup
wars", but at this point have mostly given in and switched to Markdown for
ubiquity's sake. There are still things that reStructuredText has done for a
long time that Markdown could learn from (standardized extensions, for
instance).

Hopefully, maybe one of these days CommonMark will finally get everybody on
the same page, in the future.

Kramdown, at least, from what I've seen seems to be the most useful superset
of CommonMark. I'd love to see CommonMark updated to reflect more of the
Kramdown default extensions.

As for some of the specific formatting issues the author found in Kramdown:
backtick code fences are supported with the Github-Flavored Markdown option
turned on, which now should be the default on GitHub Pages. Smart quotes are
also an option you can turn on in Kramdown, although I ended up using
typogr.js [1] for this personally.

Also, I shuddered at the idea of XML being a "better" alternative to Markdown,
but to each their own (blunt force hammer).

[1]
[https://github.com/ekalinin/typogr.js](https://github.com/ekalinin/typogr.js)

