纯粹的 Markdown

Markdown 规范和扩展

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

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

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

前进还是倒退

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

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

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

用户视角

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

Markdown 显然是前者。

广告 我要投放

11 回帖

欢迎来到这里!

我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。

注册 关于
请输入回帖内容 ...
  • zjp 1 赞同
    支持者 订阅者

    md 本来就不是为了复杂的记录而生的。。。何必赋予它什么职责或者指责呢?

    1 回复
  • 其他回帖
  • xuanlemming
    支持者 订阅者

    其实纯粹与否并不重要,用户需要的只是好用和功能强大。或者说,在功能强大的基础上,尽可能地保留 md 标准化地输出(分享和迁移),要是能完美导出为 word,感觉也没必要保留 md 格式输出了,因为这算是通用的格式了。我倒是并不觉得 md 多简洁和易用,如果只是好用的 md 工具(替代品实在是过于丰富),那么永远脱离不出 md 的设计框架,那又谈什么进步?更自信一点,真的有很好的设计,其实是会带动它本身的流行的,就像这波双链。

  • abbj 1 3 赞同
    支持者 订阅者

    markdown 的高可读性,其代价是牺牲了功能或者特性的完整性和可扩展性。用户可以任性的提出需求,他们总是希望能有更丰富更强大的功能,同时还希望尽可能的自由(高度的可迁移性,不被某个平台绑定)。

    实际上,由于各平台总有自己独特的功能,功能的完备必然意味着迁移性降低,用户不能要求当前平台的独有特性导出标准 markdown 后能无损迁移到新平台。因此,个人认为,开发者在不断完善功能的前提下,提供尽可能完善的标准 markdown 导出导入支持(如思源笔记目前做的),已经是现实情境下所能做到的最好选择了。

    所以,在支持导入导出标准 markdown 的前提下,建议开发者避免因有意无意的标准 markdown“洁癖”而影响程序的整体设计,不要让程序的功能或性能被“markdown 情结”拖了后腿,只要能增强整体体验,就大胆的“开倒车”。

    感谢 D V 两位兼具情怀、实力和毅力的开发者。

  • rocklaw 1 1 赞同
    支持者 订阅者

    相当于要求用土豆丝做出满汉全席来,这不是强人所难嘛,肯定要加菜啊。请 D 大 V 姐放心大胆地加 😄

  • 查看全部回帖