各位的意见对我帮助还是挺大的，我准备再如下几方面改进：

1. 原来设定完全不用行首的水平空白作为标记，现在放弃这样做。许多时候，行首空白还是很有用的，适当利用行首空白进行标记能使文档更加美观。
2. 进一步多参考 Markdown 以及其他标记语言的优点，让显示效果更漂亮一点。
3. 想办法简化自动编号、图、表、公式、参考文献的表达，但还是想办法保留对编号的各种设置，毕竟这个东西真的很有用。
4. 设法使文档书写过程中基本可以不用转义。
5. 改个名字！

不过，还是要保留目前这种方括号对接龙的标记语法（只是对部分块级元素，可以通过简化而不写方括号），以及对额外的元素类型、属性的支持，从而使其具有与 HTML 相匹配的表达能力。毕竟，如果不这样，就没有存在的必要了。

谢谢各位！

@pluvet 这个和 Markdown 差别太大，没办法兼容啊。

@leokino 作者对于[][]部分元素渲染的构思以及表格的展示还是很有创意的。乱码了，不知道你写的“[][]”是什么。

@yafoo 自己基于 Hugo 设计的一个非常轻量级的主题，css 文件就一个，在 gzip 压缩前才 19kb，不过我还不太精通 Hugo 主题发布的全套流程，所以没有开源。

@zjm947373 有道理！

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

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