Why Markdown sucks

Individual sites&#x2F;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.)<p>Ultimately though, if you need control then you have to <i>take</i> control.<p>I have been using &quot;textile&quot; 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).

I carried the banner for reStructuredText for a while in the &quot;text markup wars&quot;, but at this point have mostly given in and switched to Markdown for ubiquity&#x27;s sake. There are still things that reStructuredText has done for a long time that Markdown could learn from (standardized extensions, for instance).<p>Hopefully, maybe one of these days CommonMark will finally get everybody on the same page, in the future.<p>Kramdown, at least, from what I&#x27;ve seen seems to be the most useful superset of CommonMark. I&#x27;d love to see CommonMark updated to reflect more of the Kramdown default extensions.<p>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.<p>Also, I shuddered at the idea of XML being a &quot;better&quot; alternative to Markdown, but to each their own (blunt force hammer).<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;ekalinin&#x2F;typogr.js" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;ekalinin&#x2F;typogr.js</a>