纯粹的 Markdown

Markdown 规范和扩展

Markdown 正是因为其简约和通用性才得以流行，通过 GFM/CommonMark 规范进行标准化以后 ，几乎宣称支持 Markdown 的平台和软件都已经做了实现。

目前来说，这是公认“纯粹”的 Markdown，没有那么多“花里胡哨”的东西。用户可以放心使用，通用性和迁移性能够在最大程度上得到保证。

但 GFM 规范不能满足一些“现代化”的使用需求，所以很多软件引入了一些扩展语法（比如上标下标、脚注、公式、图表等），这些扩展语法虽然不一定能在其他平台和软件上通用，但能够满足用户在该平台和软件上的特定需求，然后通过导出功能提供更广泛的格式支持。

前进还是倒退

在扩展语法的道路上越走越远以后，我们发现这似乎是在开历史的倒车。随着更多特定语法的引入，Markdown 的通用性逐步散失，就好像变成了特定软件的私有格式一般。更讽刺的是，语法引入却不能解决 Markdown 最大的问题 —— 自带资源文件（虽然 TextBundle/TextPack 做了一些努力，但就目前而言基本也还是不通用）。

越强大的功能，意味着越复杂的语法，如果沿着这条路一路走下去，语法的复杂度可能会超过人类的可读能力，这将彻底失去 Markdown 的意义。

对于开发者来说，另一条路是一开始就不选择以 Markdown 文本作为存储格式，而是使用更结构化的存储方式，比如数据库或者 JSON，然后在应用层面支持 Markdown 语法排版。选择这条路的开发者，也许已经预见到了将来可能的复杂场景。

用户视角

• “我要 Markdown 标准规范文本，这样其他软件也能够编辑查看”
• “我要所见即所得编辑，分屏的割裂感太令我难受”
• “我要源码编辑模式，这才是 Markdown 的精髓，况且我能肉眼渲染……”
• “我要给文字加颜色，我要横向布局，我要图片缩放”
• “我要表格嵌套、合并单元格”
• “我要……”
• “什么？这都不行，告辞！”

只有两种语言：一种被人抱怨，而另一种没人使用。

Markdown 显然是前者。