@TankyWoo 写 IT 博客会比较好。谁都不希望 GitHub 再次因为某些原因被墙什么的。

@lleon 那样会严重降低可读性的，其实也不会经常用到特殊格式。

@acgtyrant 代码高亮可以用其它方法实现，只要能否指示代码类型就可以了。

@mytharcher 噢，这个啊，我是用正则按顺序轮流匹配，直到找到符合的文本块。Javascript 上的正则往往比单字符循环判断快，其它原生支持正则的编程语言可能也有这个优势吧。我优先考虑 Javascript/NodeJS ，PHP 、Ruby 、Perl 想移植也不困难。C/C++ 的话可能真的比较麻烦。

@mytharcher GFM 的庞大社区影响无可厚非了……我想过坚持使用原生 Markdown ，只可惜没有找到语法解析 bug 比较少的 Javascript 写的工具，最多问题的地方就是行内嵌套了，因为这里从来没有标准，也不知道自己从这个所谓的原生 Markdown 转换工具切换到另一个所谓的原生 Markdown 转换工具之间会不会发生什么不愉快的事情。因此我要求语法尽量少产生歧义，而且至少得有个 Javascript 写的转换工具（服务器可以用 NodeJS）。毕竟用得爽才是真道理啊，Markdown 的作者当初设计时这么随意（说不定他已经用得很爽），就不必管他的 Markdown 了。

** 的确比 * 更适合混合文本，这里我也认为不兼容原生 Markdown 会更方便一些。至于下划线和删除线，我提倡分别用 __ 和 ~~ ，-- 会不利用提供将其转换为 – (—) 的扩展功能。斜体可以用 // 。行内语法我觉得不接受嵌套会比较好，可以保持可读性。

DokuWiki 的脚注语法其实并不好，会降低可读性，kramdown 的更好。

定义列表有计划加入，不过我没想过会产生回溯的问题，不知道你提到的讨论具体是怎样的？

@Tink 这个我可以尝试通过扩展（图片）链接的定义或者直接新增属性表语法来实现。

@oott123 大致上兼容吧，带有块级元素的列表项目的 <p> 元素自动方式会有冲突，列表项目之间可以用空白行分隔。除了列表项目和缩进式代码块之外，块级元素之间都用空白行分隔。

PHP Markdown Extra 的表格的确是挺好看，虽然功能比 DokuWiki 的少了一些。唔，看来我要考虑一下放弃合并表格单元的功能了，或者合并两者的功能……=_=

@RIcter 不知道 GFM 的哪些语法比较吸引你？如果是表格语法，可以和 DokuWiki 的比较一下：

https://www.dokuwiki.org/wiki:syntax#tables

@znx5858 CSS 用 text-indent 可以实现，只是列表元素可能要添加一些额外设定。可以参考我的博客。

@terrance 其实我还没有这么大的目标呢。我不是很擅长编写解释器和转换工具，目前借鉴 marked 这个 Markdown 转换工具的代码，能够达到日常写作的用途是我的基本目标了，编辑器倒没有大的要求，尽量采用一种方便普通文本编辑工具的表格语法（目前看好 DokuWiki 的表格语法）。

我希望定好规范，弄好 Javascript 写的转换工具后有人能够移植或者帮忙改进算法。我有在编写 Javascript 解释工具时考虑严格带来的好处和坏处，相信好处是更多的。目前我是用正则表达式来匹配各种元素的，因为浏览器上的正则貌似比纯粹的字符循环快很多。

我对其它编程语言不怎么熟悉呢，可能没有精力去继续编写维护其它语言的工具了。不过我会尝试将这个变种应用到我以后的网页应用上的。

@chenlong451 你觉得 DokuWiki 的表格语法怎么样？https://www.dokuwiki.org/wiki:syntax#tables

@hkongm 没关系，那些经常写（技术）博客或将要编写 MD 相关的软件的人用得着就行了～ reStructuredText 更小众啊，不过已经帮助我分享了上百篇文章了～

@icylogic 功能上应该是着重于 HTML 转换方面吧，语法设计上更考虑日常写作的可读性，若去除扩展功能，则几乎相当于语法更严格的 Markdown 。另外表格和标题目录应该算作可选扩展功能。

用 Javascript 写的转换工具不考虑自带代码高亮功能，不过会提供自定义高亮措施的选项。也会提供某些扩展功能的开关（例如 HTML 嵌入功能、表格功能、印刷字符转换功能、和文本缩进以及代码尾部空白行有关的偏执模式）。

TOC 支持有点让人纠结呢，肯定要做成带开关的扩展功能的，不知道生成的列表元素要用什么方式包裹，同时包括目录名称比较能令人接受。这个支持必定会涉及标题的链接中转位置，标题目录是否要带数字前缀的选项，是否允许用户提供自定义 HTML 生成函数。

当然我希望越全越好，只要是利于普遍的日常写作。功能只考虑那些可读性比较好的，扩展功能除了 kramdown 介绍的部分功能以及 TOC 之外，我想不会有其它更常用的功能了吧。

我用 Javascript 写的转换工具是借鉴 GitHub 的 marked 和 markdown-js 的，想要自行修改或扩展应该会挺方便的。

我不知道这个变种以后会不会流行呢，总之我会搞定那个 Javascript 语言写的 HTML 转换工具的，至少能用于前端或后端的 Javascript ，摆脱语法不够严谨且功能过少的原生 Markdown 。

@oott123 是的，因为 Markdown 并不是专门针对 HTML 文档而设计的。但是若要转换为 HTML ，没有表格功能多少会有点不便。

DokuWiki 的表格语法我觉得十分好，因为它不要求对齐表格线，也没有设定表格宽度这些不太重要的功能，左中右对齐语法也很简单而不碍眼。

@faceair 抱歉抱歉……我对网络爬虫设的屏蔽规则有一条太夸张了……现在去缓存应该可以访问了。

啊，忘了说了，我设计的这个变种，语法上是要求更严格的，尽量去除原生 Markdown 的语法歧义，所以我才真觉得的有必要实现这个变种。