原始的Markdown“规范”非常模糊且未得到维护。当然有perl脚本markdown.pl，这是“参考实现”，但它有很多常见的怪异之处。
您可以加入列表http://six.pairlist.net/pipermail/markdown-discuss/，该列表永远在抱怨Gruber的腐败导致这种矛盾的情况。也许列表用户会有意识地处理此事，尽管不同实现之间的微妙差异和不同扩展之间的明显差异使此事变得困难。-特别是在Gruber不放弃有关此事的所有权利但同时不推动任何规范的情况下。如果组建委员会，则无法将任何规范视为Markdown的规范。
原则上，块引用受与非块引用相同的原则支配-例如，您可以在块引用中使用块引用-因此您的朋友肯定是错误的。您可以通过在其文本上运行markdown.pl来向用户证明这一点。任何其他原则都将是完全混乱。请注意：
带有行末额外空格的制作换行符的规则
块引用中也是如此-因此您可以向他或她解释这一点
完全明确
无论内部还是
外部
块引用，所以你可能需要向他或她解释这一点。
请注意，stackoverflow的markdown解析器在这里很好（尽管我注意到了您退出嵌套块引用以返回主块引用方式存在问题）。但css的作者错误地使块引用与周围文本之间的间距大于段落之间的间距。这是荒谬的，其中段落分隔通过额外的空格进行通信。块引用是段落的一部分，实际上通常是句子的一部分。它类似于一个非常长的单词，就像您在写作中使用的任何其他引语一样。
请注意，“GitHub™ flavored markdown”中所谓的可爱、过于甜腻的行话将
所有换行符（在代码块之外等）视为段落分隔符，这基本上使得markdown概念不存在。也许您的用户对这种东西有所了解--尽管它至少没有破坏块引用内外一致的规则。GitHub公司已经...嗯...“说服”Gruber这是一个合法的markdown“适用于他们的用例”。其依据是未受训练的人可能自然而然地认为换行符表示段落分隔符。Gruber大概意识到GitHub™的用户群体是由
程序员构成的，所以这表明标准或规范对他有多少价值。当然，这对GitHub上复杂文档产生了彻底的混乱。(为什么不应该有“Internet Explorer使用情况的合法html”？很多人只是在IE中测试一些东西，因此他们有某些合法的期望吗？当然，GitHub的决定比任何类似事情都要糟糕得多。）
我已经有一段时间没有考虑这个问题了，所以这些评论可能不是最新的，但我怀疑自从我决定不再考虑它以来，情况并没有发生变化。缺乏并将没有规范表明您每花费一分钟思考此事都是浪费人力资源。由于Gruber的浮华，Markdown现在已经引起了相当多的注意。
