这是一个创建于 4535 天前的主题，其中的信息可能已经有所发展或是发生改变。
从我在知乎被教育说 Markdown 是对技术社区很从的标记语言
到自己在 Github 和 CNode 长期使用 Markdown 发帖回帖到现在对 Markdown 产生反感,,
我并不是用 Markdown 太少, 也不是说 Markdown 在任意场景都不合适
我是说, 对于参数人数多的技术社区, Markdown 存在若干问题:
* 有人不用 Markdown 标记代码
没有高亮的代码是难读的, 用非等宽字体简直就有些可恨了
但国内技术社区, 特别新人增多之后, 不用 Markdown 的例子很多
我在 CNode 水贴, 隔几天就会遇到提问不加语法标记的
有时候行内代码, 图个方便, 也不想加代码标记了
结果就是没有标记的 log 或者代码, 各种损害网站的界面
对此我尝试了 `white-space: pre-wrap`, 以及强制等宽字体的方案
结果是空行包裹加四空格缩进的内容被标记为代码块, 代码依旧出现问题
而去掉代码区域标记使之融入背景的做法又导致大量反感
剩下只有让 Markdown 不标记缩进代码, 改动编译器, 同样不成
* 控制复杂的空行
```
* item
* item
```
和
```
* item
* item
```
因为中间空格的关系, 可能会被加上一层 `<p>` 标签来标记为段落
Markdown 对换行的处理纠缠已久, 很可能就会在书写时多个少个空行
同个人写还是能统一间距, 但论坛上喜欢未必统一, 于是 CSS 设置的间距就不定了
同样创建更多的空白在 Markdown 里并不是那么自由, `\n\n` 会被压缩
* 不是所见所得
个人博客上的 Markdown 由自己控制, 虽然坑人, 但遵守规范时视觉效果稳定的
但论坛上的, 一般是修改了手动点击按钮切换预览, 写长文就很蛋疼了
在处理 CNode 问题的时候, pre-wrap 带来更多的影响, 问题特别明显
因为不是所见所得, 排版成了不小的问题.. 但同时也被其他影响放大
* 缩进的编辑器支持
既然 Markdown 支持编辑代码, 就很自然有想在输入框编辑代码的需求
但 Web 上的 `<textarea>` 默认就没有自动管理缩进的功能
引入第三方的编辑器反而页面和编辑工作显得臃肿, 不如文本框那么轻便和熟悉
------
个人博客, 高素质的社区, 我不感到 Markdown 有不适
但通常技术社区都是有大量新人涌入, Markdown 本身对新人是门槛
而新人使用不恰当对社区整个排版也造成各种影响..
因此我认为 Markdown 不合适
到自己在 Github 和 CNode 长期使用 Markdown 发帖回帖到现在对 Markdown 产生反感,,
我并不是用 Markdown 太少, 也不是说 Markdown 在任意场景都不合适
我是说, 对于参数人数多的技术社区, Markdown 存在若干问题:
* 有人不用 Markdown 标记代码
没有高亮的代码是难读的, 用非等宽字体简直就有些可恨了
但国内技术社区, 特别新人增多之后, 不用 Markdown 的例子很多
我在 CNode 水贴, 隔几天就会遇到提问不加语法标记的
有时候行内代码, 图个方便, 也不想加代码标记了
结果就是没有标记的 log 或者代码, 各种损害网站的界面
对此我尝试了 `white-space: pre-wrap`, 以及强制等宽字体的方案
结果是空行包裹加四空格缩进的内容被标记为代码块, 代码依旧出现问题
而去掉代码区域标记使之融入背景的做法又导致大量反感
剩下只有让 Markdown 不标记缩进代码, 改动编译器, 同样不成
* 控制复杂的空行
```
* item
* item
```
和
```
* item
* item
```
因为中间空格的关系, 可能会被加上一层 `<p>` 标签来标记为段落
Markdown 对换行的处理纠缠已久, 很可能就会在书写时多个少个空行
同个人写还是能统一间距, 但论坛上喜欢未必统一, 于是 CSS 设置的间距就不定了
同样创建更多的空白在 Markdown 里并不是那么自由, `\n\n` 会被压缩
* 不是所见所得
个人博客上的 Markdown 由自己控制, 虽然坑人, 但遵守规范时视觉效果稳定的
但论坛上的, 一般是修改了手动点击按钮切换预览, 写长文就很蛋疼了
在处理 CNode 问题的时候, pre-wrap 带来更多的影响, 问题特别明显
因为不是所见所得, 排版成了不小的问题.. 但同时也被其他影响放大
* 缩进的编辑器支持
既然 Markdown 支持编辑代码, 就很自然有想在输入框编辑代码的需求
但 Web 上的 `<textarea>` 默认就没有自动管理缩进的功能
引入第三方的编辑器反而页面和编辑工作显得臃肿, 不如文本框那么轻便和熟悉
------
个人博客, 高素质的社区, 我不感到 Markdown 有不适
但通常技术社区都是有大量新人涌入, Markdown 本身对新人是门槛
而新人使用不恰当对社区整个排版也造成各种影响..
因此我认为 Markdown 不合适
 | 1 Perry 2013-06-10 17:18:52 +08:00 这些都不是Markdown本身存在的错误吧 既然一个社区要用到Markdown，那么必要的tutorials还是有的。 |
 | 2 jiyinyiyong OP @Perry 对, 没说是 Markdown 错误, 主要是不通用, 不合适 基本的教程在 CNode, Ruby China, Github 都是发帖时很容易看到的 但对于新手来说, 只有主动和他们直接说两边遍才是充分的 |
 | 3 davepkxxx 2013-06-10 17:37:57 +08:00 等宽字体不是 CSS 的事情吗？和 Markdown 有什么关系？ |
| 4 jiyinyiyong OP 没有用 Markdown 标记的代码, 只能用两条 CSS 来减缓 当然这已经超出 Markdown 的考虑范围了 |
 | 5 otakustay 2013-06-10 21:07:20 +08:00 我认为的markdown的主要问题： 1. code块不能指定是什么语言（于是有了gfm） 2. 没有table、dl的支持（于是有了markdown extra） 3. 没有abbr、mark的支持，这个暂时无解，而abbr在技术社区很有用 4. 没有ins和del的支持，这个是非常严重的问题 4. *错误*地将em和strong用同一个符号以不同数量为区分进行标记，这个我认为是硬伤，em和strong很常用，因此更应该用不同的符号，如*标记em，而_标记strong，而不是以*和**来区分 |
| 6 jiyinyiyong OP @otakustay 基本同意, 但我觉得我对 Markdown 的期望其实也不在乎它其实很多毛病了 如果有更完善的所见所得的编辑器方案, 相信 Markdown 依旧是问题重重 |
Select Language