Markdown艰难的标准化之路
veekxt 发布于 2018-08-16 00:06:35

Markdown虽然易读写, 但John Gruber在2004年设计的版本有着诸多模糊不清的地方. 如果你使用过不同版本的markdown解释器, 可能就会亲身感受到没有通用标准带了的麻烦. 因此pandoc的作者John MacFarlane及Jeff Atwood等人决定建立一个markdown标准.

开发组自然想要联系原作者John Gruber, 期望他加入进来, 但John Gruber却一直没有回应. 再后来项目组决定将新标准命名为 "Standard Markdown". 但John Gruber却发来了邮件,表明自己很生气(infuriating), 并要求得到道歉, 重命名"Standard Markdown"项目, 新项目不能使用域名 standardmarkdown.com, 无论原作者是怎么想的, 他既然提出了这些要求, 开发组只能欣然照做, 这也是理所当然的.

最后新标准确定了名字, 就是现在的CommonMark.

commonmark的文档指出了旧标准的一些问题, 和模棱两可的地方, 比如说:

  • 子列表的缩进数是多少?
  • 缩进代码块之前是否需要空行?
  • 列表的确切规则,比如下面的文本到底是几个列表?
    1. one
    2. two
    - three
    - four
    
  • 强调的规则,文本 *foo *bar* baz* 到底强调哪些部分?

等等这些. 似乎新标准要做的事情只是确切一些规则而已, 而且markdown本身也不复杂, 然而现实却很残酷, 2016年时,官网就写着将会完成1.0版本. 然而已经2018了, 新标准仍未完成. 离最初开始设计已经过去了四年. 不过还是有一些好消息, 比如github已经在使用commonmark了.

commonmark的主要问题是要在原有的语法上消除二义性并增加一致性是十分困难的, John MacFarlane在近期发表了文章, 其中提到, 如果当初保留markdown核心的优点, 重新设计语法, 将会怎样? 不过事已至此, 重新设计语法是不切实际的. 他解释了6个markdown难以解决的问题并提供了解决思路.

问题主要在:

  • 强调的嵌套问题, 比如如何解析**this* text**
  • 多个参考链接的相连问题, 比如[foo][bar][baz]
  • 代码块和列表的缩进问题
  • 插入HTML的问题, 比如如何处理html内的markdown?
  • 列表和换行问题, 比如列表能否打断换行?
  • 如何添加"属性"

详细信息见原帖.

注意并不是说解析某种格式或者语法有困难, 而是这些语法产生了一些相互冲突或者不一致的结果, 需要额外的规则去规定如何解析, 以至于最后根本没有满意的解析方案. 比如当前的标准中, 有多达17条规则是用来解决"强调问题"的.