纯粹的 Markdown

Markdown 规范和扩展

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

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

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

前进还是倒退

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

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

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

用户视角

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

Markdown 显然是前者。

广告 我要投放

12 回帖

欢迎来到这里!

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

注册 关于
请输入回帖内容 ...
  • xuanlemming
    支持者 订阅者

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

  • 其他回帖
  • zengchen 1 1 赞同
    订阅者

    我觉得 纯粹的 md 在现代并不是一个好的笔记格式, 就像楼主你说的, 没有扩展语法, 各种资源也不好统合.

    我之前是用 三维软件的, 像文件格式, 从 obj, 发展到 abc, 再一步步发展到现在乃至未来的通用场景格式 usd.
    本来就是越来越复杂, 但同时也越来越方便人员操作, 因为 usd 把三维制作里所有东西都包裹在一起, 并进行分层, 不再需要操作人员在各个模块来回切换, 而只要一个 usd 就表示一整个三维场景, usd 格式也不再仅限于一个 点线面 (类似 obj 的) 文件 .

    这就好比笔记格式从 单纯的 md 格式 进化成一个 支持 md 语法并可以浏览, 修改并打包 公式, 流程图, pdf, execl 等的一个玩意.

    就像楼主你说的 :

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

    我觉得这是一个发展方向, 我个人也认为原始纯粹的 md 本身并不适合做笔记.
    这并不像更简单 json 取代复杂的 xml 那样, 因为用途不一样, 我觉得 用 usd 做类比, 展望笔记的未来才更合适.

    但可惜的是, 在现在笔记市场上, 并没有哪家公司有这么重的话语权和能力, 能像皮克斯之于三维制作, 开发出 usd, 并进行开源和推广.

    1 回复
  • devcui
    捐赠者

    万变不离其宗,用户用起来觉得好用顺手,自己要的功能都有便可

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

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

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

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

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

  • 查看全部回帖