@2i2Re2PLMaDnghL 我原来也是想着在 InkMark 中可选性地允许多层方括号，但要求左右两侧的方括号数目必须相等，这样可以规避该问题。例如：

` [[
s.find("]")
]][Python]

后来觉得规则太多，就没有用。现在其实还是应该考虑一下这个规则。

@2i2Re2PLMaDnghL 嗯，的确存在这个问题。目前的做法是对方括号进行转义。Markdown 中 `s.find("`")` 似乎也存在同样的问题，无解啊。

BTW: pfm 是什么啊？

@easychen 在 Markdown 中禁用了 HTML，剩下的功能对学术表达就不够用了，甚至连简单的上下标都需要借助嵌入 LaTeX 公式实现，实在是有点麻烦。

@nowgoo 的确，需要改！

@bailitusu 1. 不应该考虑排版风格的，所有轻量级标记语言都是内容和样式分离的，只要支持文档中的各种要素，应用不同的 CSS 就有不同的样式。

2. 在网页中嵌入 pdf 不方便啊，比如就不方便响应式排版，在手机上看就很不方便。

3. 你举的这个例子排版效果很差啊，跟维基百科这种用简单标记语言生成的页面差距很大。LaTeX 那么难，长远来说，为什么一定要用它呢？

当然，想要 InkMark 适应学术论文出版的需求，还需要做些扩充，如为文档添加元数据，这些都是比较容易实现的。

@icyalala 哎呀，我在第二个文档中用了长长的一段话描述，写得有点啰嗦了，看了应该将它缩减矿一句话更好。先把这段话放上来吧：

“为了能在浏览器中轻松编写并正确地展示格式复杂的学术内容，我们需要做一些折中。即不完全依赖所见即所得的 HTML 编辑器，而是让用户以纯文本的形式输入内容，纯文本中包含一些简单的标记，用于标示文档的各种元素及其属性，之后通过编译过程将这些被标记的文本转化为网页内容（ HTML 格式的文本）。当然，这些标记规则要容易记忆、便于输入、可读性好。基于最新的 Web 技术，这些标记文本被编译后生成的网页看起来完全可以像正规的出版物一样，甚至在交互性操作、多种尺寸屏幕上的自动调整版式显示还优于以往常用的便携式文档格式（ PDF 格式）或 MicroSoft Office Word 文档。”

@bailitusu @cmdOptionKana 至于会不会有人用，我也不知道。可是，如果解决 LaTeX 过难的问题，且做到内容和样式分离，功能上配合 CSS 、JavaScript 也不输太多，还方便在网页中呈现，为什么就没有前途呢？

——当然，我自己不一定能把这个事情做好。我发在这里是为了争取支持的。

@easychen 看了这个 PHP Markdown Extra，它定义属性的方法跟 InkMark 差不多。我觉得它还是存在如下问题：

* 为了扩展功能，它还是使用 Markdown 和 HTML 混排，这时 InkMark 设计时力求避免的。
* 在 Markdown 中嵌套 HTML 块级元素时，其用空格缩进的规则还是挺增加心智负担的。
* 为了在 HTML 块级元素内包含其他 Markdown 元素，用 `<div markdown="1"> </div>` 的形式的 HTML 块级元素一点也不优雅；同样，为了在 HTML 表格单元格内包含 Markdown 块级元素，用 `<td markdown="block"> </td>` 形式定义单元格也不优雅。
* 它无法为所有 Markdown 元素指定属性。

我觉得把 Markdown 搞复杂了，就会变成一个大杂烩。

@learningman 嗯嗯，程序员用 Markdown 肯定是很不错了。但在学术文档中，即便内联 HTML，也是不够用的。主要是自动编号、交叉引用、索引那一套不够用；另外内联 HTML，毕竟还是有点不好看，对普通人学习成本有点高了。

@queuey 这个……其基础功能……没有那么难吧？我觉得比 Markdown 还简单，就是高级功能有点复杂。

@ebingtel 事情总是一步步来，我不能闷着头干，如果大家根本不喜欢这个语法，我写解析器就没有意义了。

@snailya 是的。InkMark 要通过自身的标记功能，配合外部 CSS 和 JavaScript，实现这些特殊的需求。

@Veneris 大的方面不会有冲突的。至于比较复杂，我也是没办法，因为复杂问题的解决方案往往比较复杂。我这个自动编号功能是针对 Word 中的题注、交叉引用和索引功能设计的。

@AX5N 请不吝指出问题。

这么复杂的一个东西，我若不是思考及实践很久，是弄不出来的。我现在是把整个思考过程都清晰地写出来了，这并不容易。我自己也用这个语言记笔记，期间对其设计语法作出了很多改进。但只要持续思考，就必然仍有很多改进的空间。我的确没有写出其解析器，我没有精力，并且也不是应该首先做的事情。

您既然设计过同类的语言，肯定很容易看出这个东西的缺点。我把这个东西放这里就是找别人批评的，很期待你的详细点评，不过还是应该以和我同样的设计出发点，即写作复杂的学术文档的角度来进行评价。

@namelosw 你都说到点子上了。我设计的这个东西的确解决了你所说的 Markdown 的两个问题，但太多的方括号使其看起来有点丑陋。

我现在只是部分解决了方括号过多导致丑陋的问题，就是规定若块级元素只占一行时，可以不写方括号。另外，当列表项元素包含多个段落时，也可以通过使用斜线表示的接力棒 / 标记而不使用方括号。

虽然用方括号很丑陋，但是针对我想解决的问题，我找不出更好的方法。比如，学术文档中往往一个表格单元格内还包括多个段落，我找不出除了用括号外能更好地包括这多个段落的方法。另外，我也找不出不使用括号而给元素添加属性的好方法——为元素添加属性在实现复杂的功能时真的很有用。用括号还有一个好处，就是元素内容的边界清晰，学术内容可能包含各种标点符号，像常规的用 *强调* 形式的标记方法，很可能和内容中的乘号相混淆。

Markdown 中的缩进规则是比较复杂的，我觉得除了程序开发人员，其他人员对多少个空格根本不敏感。我常常给学生们改 Word 论文，其中存在太多的胡乱用空格的情况。甚至好多时候，文档中多出一些空格他们都会视而不见。因此，我从最初的设计时，就排除了利用行首和行尾水平空白作为标记的方式，即完全忽略标记内容开始和结尾的空白。

我也看了许多已有的标记语言（但没有全部看完），都不如 Markdown 那样简单明了。大多数标记语言大都针对每个元素类型设计了独特的标记规则，标记方法太多，不好记忆，在 InkMark 中也不够用。我这里力求规则一致。但这个文档看起来仍然复杂，主要是因为自动编号元素有点复杂了（其中的 number 和 template 属性看起来有点像模板语言），以及对属性的支持使得格式有点凌乱。

另外，我在设计时，也并不是一直想着要简单。因为复杂的问题往往必然只能有复杂的解决方法。看看 MediaWiki 的标记语法，虽然基本语法比较简单，但完全不够用，必须配合使用 HTML 以及模板，大多数维基页面都充斥着这些复杂的混合标记。所以我不如一开始就把一些功能设计得稍微复杂一点，可扩展性强一点。当然，我现暂时在还不敢往里面加模板功能，那样就太复杂了。

对于非编程开发人员，我现在第一担心的是他们能不能分清行内元素和块级元素，而我设计的这个标记语法在进行标记时，必须首先能区分这两类元素。

@Kilerd LaTeX 比这个复杂多了，我认为有点不适合现代的面向 Web 的写作。

@eason1874
这个也没有太复杂，主要是我确实是从设计思想的角度写了比较多，没有从初学者的角度写。

学术写作还是比较复杂的，面对复杂的问题，也往往只能有复杂的解决方案。

可以看看 CommonMark 的规范，如果用 Chrome 的打印功能，A4 纸默认样式下也要 114 页了，我这个才写了 71 页。

@namelosw 真要写复杂的学术内容，Markdown 还是差很远，并且好多都是系统性的问题，改不动啊。

V2EX 的用户大部分都是搞编程开发的，对复杂的学术文档的写作需求的理解并不是很清晰。看来我的确需要从初学者的角度再写一个文档，这样才能让大家明白我究竟想怎么做。

@stimw 嗯，的确。因为我暂时没有精力写一个入门介绍文档，导致很多人都不会仔细去看和推敲。

不过写个中文文档都耗费了很大精力，写英文就更难了。因为要考虑很多细节，感觉这个东西比做个博士论文还累。

@oott123 是的。应该弄个简单的例子。我附加了一点点。

@renmu123 我主要是在 Markdown 和 HTML 之间取得平衡，的确很难把握。但我现在的构想已经做到了：写简单文档时，真的就像 Markdown 一样简单，其规则甚至比 Markdown 还简单（但不如 Markdown 美观）；随着需求的增加，慢慢去了解一些更复杂的功能，发现还是可以做到。

@humpy 淘气，你说的这个名字不好听。

以前在京东买书的时候，喜欢在一家店把所要买的书凑齐。在当当购买，你根本看不到这家商铺还有卖其他什么商品，导致不得不在多家购买。现在每本书打电话过来，都说我只在人家这里买了一本。所以如果我要吐槽，似乎只能吐槽当当网上的不良店铺。

但实际情况是，我就这么随机买 5 本书，都点最前面当当推荐的链接购买，有 4 本都是旧书，还在同一个城市。所以我分析，这个操作有很大可能是当当自己弄的马甲来卖旧书的，不然其平台的店铺这么嚣张，当当不可能不知道，甚至会配合商家把店铺的所有信息抹去，只剩下店铺首页一个带有警告性质的图片公告。

@gilgameshcc 你说的这两个似乎都有共同的卖点——类似于 MediaWiki 内部链接的功能。有时间我也多了解一下他们。

另外我原来也是想针对 Markdown 修修补补，但后来发现无法满足我的主要要求，干脆就来个系统性更改。

@flyhelan 谢谢，我自己的精力就只能把规范写出来，编程实现我没功夫做，到时候就在 Github 上把规范公开发布出来。不过感觉大家都不太在意这个，或许这种设计不太吸引人，收到的反馈太少了。