[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"content-why-richtext-editor-on-web-is-terrible":3,"$f2i20yy17hosyd":21},{"id":4,"type":5,"slug":6,"title":7,"date":8,"category":9,"tags":10,"body_markdown":13,"permalink":14,"excerpt_src":14,"media_type":14,"media_title":14,"media_author":14,"media_url":14,"rating":14,"layout":14,"pv":15,"admin_only":15,"created_at":16,"updated_at":16,"deleted_at":14,"status":17,"html":18,"excerpt":19,"cover":20},181,"article","why-richtext-editor-on-web-is-terrible","为什么web富文本编辑器是天坑？","2017-03-15 10:17","web",[9,11,12],"富文本","编辑器","\n知乎看到一个问题，《为什么都说富文本编辑器是天坑》。里面的答案挺有意思的，各位做web前端的大牛们都有自己的切肤之痛。有兴趣的可以手工复制以下网址查看：\n\n\u003Chttps:\u002F\u002Fwww.zhihu.com\u002Fquestion\u002F38699645\u002Fanswer\u002F108376836>\n\n但是这些答案大部分还是停留在碰到的问题上面，而没有去深入总结和思考富文本编辑器背后的需求和实现思路。正好前两年在medium上看到一篇文章，叫《Why ContentEditable is Terrible》，推荐给大家。原文可点击左下角链接查看。\n\n\u003Chttps:\u002F\u002Fmedium.engineering\u002Fwhy-contenteditable-is-terrible-122d8a40e480>\n\n\u003C!-- more -->\n\n以下为简略意译版本：\n\n【一段引子，大意就是表示作者在富文本编辑器的问题上已经思考了一年了。】\n\n从数学证明的角度来说，ContentEditable在富文本的编辑这件事上是有问题的（broken，也许应该翻为烯烂？）。\n\n首先，什么叫作“所见即所得”（WYSIWYG）？当你选中一段文本按下回车的时候会发生什么？这些问题的定义并不是很清楚，而从数学证明的角度可以首先弄明白我们要研究的问题是什么。\n\n什么叫所见即所得？一个好的所见即所得编辑器应该遵守以下三条公理：\n\n- DOM内容和可见的内容的映射应该是工作良好的（well-behaved）\n- DOM选区和可见的选区的映射应该是工作良好的（well-behaved）\n- 所有可见的编辑操作应该映射到对可见内容的一个代数闭域和完整集合\n\n我将会解释这三条分别是什么意思，以及富文本编辑器为什么应该遵守这三条规则。但是首先我们要记住，公理是不需要证明的，所以它们的正确性先不作置疑。\n\n接下来，我们会看到ContentEditable无法遵守上面的任意一条公理。\n\n最后我们来看一看一些解决方案，以及Medium的富文本编辑器如何解决这个问题。\n\n。。。敷衍的分隔线。。。\n\nDOM空间是指页面的内在结构，而可视空间（WYSIWYG）是页面的渲染结果。当我们说两个页面一样时，是指他们在可视空间看起来一样。\n\n浏览器的渲染引擎做的工作就是将DOM空间映射到可视空间。即对DOM x来说，可视空间 = 渲染函数Render(x)。\n\n当我们说一个映射工作良好（well-behaved）时，是指所有的编辑操作都能在映射中反映出来。如果用E表示编辑操作，x和y表示DOM，则有\n\n- 如果Render(x) = Render(y)\n- 那么Render(E(x)) = Render(E(y))\n\n这其实是在处理“所见”之后的“所得”部分。即如果两个页面看起来一样，我们对它们做相同的编辑操作，那么操作之后的结果应该仍然看起来一样。\n\n事实上无数的富文本编辑器无法满足这个假设。看例子\n\nThe [hobbit](http:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FThe_Hobbit) was a very well-to-do hobbit, and his name was *_Baggins_*.\n\n对应的DOM大概如下\n\n```html\nThe \u003Ca href=”http:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FThe_Hobbit\">hobbit\u003C\u002Fa> was a very well-to-do hobbit, and his name was \u003Cstrong>\u003Cem>Baggins\u003C\u002Fem>\u003C\u002Fstrong>.\n```\n\n对于粗体和任何的部分，有非常多的编码方法\n\n```html\n\u003Cstrong>\u003Cem>Baggins\u003C\u002Fem>\u003C\u002Fstrong>\n\u003Cem>\u003Cstrong>Baggins\u003C\u002Fstrong>\u003C\u002Fem>\n\u003Cem>\u003Cstrong>Bagg\u003C\u002Fstrong>\u003Cstrong>ins\u003C\u002Fstrong>\u003C\u002Fem>\n\u003Cem>\u003Cstrong>Bagg\u003C\u002Fstrong>\u003C\u002Fem>\u003Cstrong>\u003Cem>ins\u003C\u002Fem>\u003C\u002Fstrong>\n```\n\n从编辑器的角度来说，它们应该是一样的，但是从DOM的角度很难识别它们是同样的东西。\n\n很多编辑器在这方面会有问题，比如有一个空的`span`可能会导致两个ContentEditable元素看起来一样，但编辑行为完全不一样，让用户觉得很难编辑，工程师也很难调试。\n\n理想情况下，我们应该可以对DOM使用可视化编辑的指令，这些指令会保证对可视空间相同的页面进行相同编辑操作后可视空间仍然是完全相同的。\n\n。。。分隔线。。。\n\nDOM空间和可视空间的映射很抓狂，但至少是多对一的，一个DOM只会有一种可视表现。\n\n选区就更糟糕了，它是多对多映射的。\n\n```html\nhis name was \u003Cstrong>\u003Cem>Baggins\u003C\u002Fem>\u003C\u002Fstrong>\n```\n\n假设这样一段内容，光标在Baggins前面，那么光标到底是在`\u003Cstrong>`前后还是`\u003Cem>`前后？你打字的时候希望是粗体的还是斜体的还是没有任何样式的？\n\n更麻烦的是，一个DOM选区会有多种可视表示。比如“well-to-do”在“to-”后面折行了，那么在光标在第一行最后和在第二行开始对应着相同的DOM位置，但可视位置却不一样。\n\n我们设计编辑器时希望选区看起来和表现起来都是一样的，但是这个映射完全乱七八糟。\n\n。。。分隔线。。。\n\n【这一段举了webkit的例子，省略，只说结论】\n\n富文本编辑器可以产出非常简洁易懂的代码，但是一旦碰到来自外部的内容就蒙逼了，比如粘贴自网页或者word的内容。\n\n一个好的富文本编辑器的内容应该是对自己的编辑行为闭域的，即内容应该只来自于正常的输入和编辑，而不应该介入来自外部的内容。\n\n。。。分隔线。。。\n\n好的富文本要怎么做？Medium的思路：\n\n1. 为文档生成数据模型，可以根据模型判断是否在可视空间相同\n2. 建立从DOM到模型的映射关系\n3. 在模型上建立编辑操作的定义\n4. 将所有的键盘和鼠标操作映射到上述编辑操作\n\n1 模型\n\nMedium编辑器的模型包含两部分：一个段落列表，一个区块列表。\n\n每个段落包括：纯文本，标记（如第1个字到第5个字是粗体），图片等数据，布局数据（位置等）\n\n区域则是包含段落的一片区域。\n\n选区使用两个点来表示，每个点由段落和索引和文本的偏移量来表示。\n\n这个模型的好处是当且仅当两个模型相同的时候，可视空间才会相同，模型的任何变更都会很好地映射到可视空间（well-defined）。\n\n2 DOM到模型的映射\n\n分为内部映射和外部映射。内部映射是DOM和模型的映射，我们希望是一对一的。外部映射是当我们拿到粘贴的内容时，需要将内容映射到我们的段落-区块模型。我们希望外部映射是有损的，首先处理纯文本，然后是粗体\u002F任何\u002F链接等标记，接下来是图片和其它的格式 。\n\n将模型映射到DOM看起来类似这样：\n\n```html\n\u003Cdiv> \u003C!-- root -->\n  \u003Csection> \u003C!-- section -->\n    \u003C!-- section-inner -->\n    \u003Cdiv class=\"section-inner layout-column\">\n      \u003Cp>  \u003C!-- paragraph -->\n        \u003Cstrong>\u003Cem>Baggins\u003C\u002Fem>\u003C\u002Fstrong> \u003C!-- text -->\n```\n\n【省略一段解释对应关系的，注释中都有写了。】\n\n映射样式的时候，我们会按顺序进行：首先是A，然后STRONG，然后EM，绝不会出现A在STRONG中的情况。\n\n3 编辑操作\n\n定义了6种操作：添加段落、移除段落、更新段落、添加选区、移除选区、更新选区。\n\n所有的编辑操作都可以由这6种操作进行组合而来。在这些操作下，所有的内容都是结构良好的。这些操作直接对应我们模型的变更，而不是DOM的变更 。\n\n4 捕获编辑动作\n\n键盘和鼠标操作被映射到这6种操作中，具体而言是从ContentEditable操作中映射而来：换行（enter\u002Fctrl-m）、删除（delete\u002Fbackspace）、输入、粘贴等。我们捕获这些事件，然后阻止它们的默认动作，然后将这些动作转换成内部的编辑操作。\n\n对其它的键盘事件，我们不阻止默认动作，而是让ContentEditor进行操作，然后在事件结束后将段落和DOM再映射回模型。\n\n如果每次模型变更都全量更新DOM，编辑体验会很差，因为内容在不停闪烁。我们监听了模型的变更，尽量让DOM的变化最小化。\n\n。。。分隔线。。。\n\n【展望未来的富文本编辑器，略，都是没影的东西。】\n",null,0,"2026-08-28 04:37:17","published","\u003Cp>知乎看到一个问题，《为什么都说富文本编辑器是天坑》。里面的答案挺有意思的，各位做web前端的大牛们都有自己的切肤之痛。有兴趣的可以手工复制以下网址查看：\u003C\u002Fp>\n\u003Cp>\u003Ca href=\"https:\u002F\u002Fwww.zhihu.com\u002Fquestion\u002F38699645\u002Fanswer\u002F108376836\">https:\u002F\u002Fwww.zhihu.com\u002Fquestion\u002F38699645\u002Fanswer\u002F108376836\u003C\u002Fa>\u003C\u002Fp>\n\u003Cp>但是这些答案大部分还是停留在碰到的问题上面，而没有去深入总结和思考富文本编辑器背后的需求和实现思路。正好前两年在medium上看到一篇文章，叫《Why ContentEditable is Terrible》，推荐给大家。原文可点击左下角链接查看。\u003C\u002Fp>\n\u003Cp>\u003Ca href=\"https:\u002F\u002Fmedium.engineering\u002Fwhy-contenteditable-is-terrible-122d8a40e480\">https:\u002F\u002Fmedium.engineering\u002Fwhy-contenteditable-is-terrible-122d8a40e480\u003C\u002Fa>\u003C\u002Fp>\n\u003Cp>以下为简略意译版本：\u003C\u002Fp>\n\u003Cp>【一段引子，大意就是表示作者在富文本编辑器的问题上已经思考了一年了。】\u003C\u002Fp>\n\u003Cp>从数学证明的角度来说，ContentEditable在富文本的编辑这件事上是有问题的（broken，也许应该翻为烯烂？）。\u003C\u002Fp>\n\u003Cp>首先，什么叫作“所见即所得”（WYSIWYG）？当你选中一段文本按下回车的时候会发生什么？这些问题的定义并不是很清楚，而从数学证明的角度可以首先弄明白我们要研究的问题是什么。\u003C\u002Fp>\n\u003Cp>什么叫所见即所得？一个好的所见即所得编辑器应该遵守以下三条公理：\u003C\u002Fp>\n\u003Cul>\n\u003Cli>DOM内容和可见的内容的映射应该是工作良好的（well-behaved）\u003C\u002Fli>\n\u003Cli>DOM选区和可见的选区的映射应该是工作良好的（well-behaved）\u003C\u002Fli>\n\u003Cli>所有可见的编辑操作应该映射到对可见内容的一个代数闭域和完整集合\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>我将会解释这三条分别是什么意思，以及富文本编辑器为什么应该遵守这三条规则。但是首先我们要记住，公理是不需要证明的，所以它们的正确性先不作置疑。\u003C\u002Fp>\n\u003Cp>接下来，我们会看到ContentEditable无法遵守上面的任意一条公理。\u003C\u002Fp>\n\u003Cp>最后我们来看一看一些解决方案，以及Medium的富文本编辑器如何解决这个问题。\u003C\u002Fp>\n\u003Cp>。。。敷衍的分隔线。。。\u003C\u002Fp>\n\u003Cp>DOM空间是指页面的内在结构，而可视空间（WYSIWYG）是页面的渲染结果。当我们说两个页面一样时，是指他们在可视空间看起来一样。\u003C\u002Fp>\n\u003Cp>浏览器的渲染引擎做的工作就是将DOM空间映射到可视空间。即对DOM x来说，可视空间 = 渲染函数Render(x)。\u003C\u002Fp>\n\u003Cp>当我们说一个映射工作良好（well-behaved）时，是指所有的编辑操作都能在映射中反映出来。如果用E表示编辑操作，x和y表示DOM，则有\u003C\u002Fp>\n\u003Cul>\n\u003Cli>如果Render(x) = Render(y)\u003C\u002Fli>\n\u003Cli>那么Render(E(x)) = Render(E(y))\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>这其实是在处理“所见”之后的“所得”部分。即如果两个页面看起来一样，我们对它们做相同的编辑操作，那么操作之后的结果应该仍然看起来一样。\u003C\u002Fp>\n\u003Cp>事实上无数的富文本编辑器无法满足这个假设。看例子\u003C\u002Fp>\n\u003Cp>The \u003Ca href=\"http:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FThe_Hobbit\">hobbit\u003C\u002Fa> was a very well-to-do hobbit, and his name was \u003Cem>\u003Cem>Baggins\u003C\u002Fem>\u003C\u002Fem>.\u003C\u002Fp>\n\u003Cp>对应的DOM大概如下\u003C\u002Fp>\n\u003Cpre>\u003Ccode>The <a href=”http:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FThe_Hobbit">hobbit<\u002Fa> was a very well-to-do hobbit, and his name was <strong><em>Baggins<\u002Fem><\u002Fstrong>.\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>对于粗体和任何的部分，有非常多的编码方法\u003C\u002Fp>\n\u003Cpre>\u003Ccode><strong><em>Baggins<\u002Fem><\u002Fstrong>\n<em><strong>Baggins<\u002Fstrong><\u002Fem>\n<em><strong>Bagg<\u002Fstrong><strong>ins<\u002Fstrong><\u002Fem>\n<em><strong>Bagg<\u002Fstrong><\u002Fem><strong><em>ins<\u002Fem><\u002Fstrong>\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>从编辑器的角度来说，它们应该是一样的，但是从DOM的角度很难识别它们是同样的东西。\u003C\u002Fp>\n\u003Cp>很多编辑器在这方面会有问题，比如有一个空的\u003Ccode>span\u003C\u002Fcode>可能会导致两个ContentEditable元素看起来一样，但编辑行为完全不一样，让用户觉得很难编辑，工程师也很难调试。\u003C\u002Fp>\n\u003Cp>理想情况下，我们应该可以对DOM使用可视化编辑的指令，这些指令会保证对可视空间相同的页面进行相同编辑操作后可视空间仍然是完全相同的。\u003C\u002Fp>\n\u003Cp>。。。分隔线。。。\u003C\u002Fp>\n\u003Cp>DOM空间和可视空间的映射很抓狂，但至少是多对一的，一个DOM只会有一种可视表现。\u003C\u002Fp>\n\u003Cp>选区就更糟糕了，它是多对多映射的。\u003C\u002Fp>\n\u003Cpre>\u003Ccode>his name was <strong><em>Baggins<\u002Fem><\u002Fstrong>\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>假设这样一段内容，光标在Baggins前面，那么光标到底是在\u003Ccode><strong>\u003C\u002Fcode>前后还是\u003Ccode><em>\u003C\u002Fcode>前后？你打字的时候希望是粗体的还是斜体的还是没有任何样式的？\u003C\u002Fp>\n\u003Cp>更麻烦的是，一个DOM选区会有多种可视表示。比如“well-to-do”在“to-”后面折行了，那么在光标在第一行最后和在第二行开始对应着相同的DOM位置，但可视位置却不一样。\u003C\u002Fp>\n\u003Cp>我们设计编辑器时希望选区看起来和表现起来都是一样的，但是这个映射完全乱七八糟。\u003C\u002Fp>\n\u003Cp>。。。分隔线。。。\u003C\u002Fp>\n\u003Cp>【这一段举了webkit的例子，省略，只说结论】\u003C\u002Fp>\n\u003Cp>富文本编辑器可以产出非常简洁易懂的代码，但是一旦碰到来自外部的内容就蒙逼了，比如粘贴自网页或者word的内容。\u003C\u002Fp>\n\u003Cp>一个好的富文本编辑器的内容应该是对自己的编辑行为闭域的，即内容应该只来自于正常的输入和编辑，而不应该介入来自外部的内容。\u003C\u002Fp>\n\u003Cp>。。。分隔线。。。\u003C\u002Fp>\n\u003Cp>好的富文本要怎么做？Medium的思路：\u003C\u002Fp>\n\u003Col>\n\u003Cli>为文档生成数据模型，可以根据模型判断是否在可视空间相同\u003C\u002Fli>\n\u003Cli>建立从DOM到模型的映射关系\u003C\u002Fli>\n\u003Cli>在模型上建立编辑操作的定义\u003C\u002Fli>\n\u003Cli>将所有的键盘和鼠标操作映射到上述编辑操作\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>1 模型\u003C\u002Fp>\n\u003Cp>Medium编辑器的模型包含两部分：一个段落列表，一个区块列表。\u003C\u002Fp>\n\u003Cp>每个段落包括：纯文本，标记（如第1个字到第5个字是粗体），图片等数据，布局数据（位置等）\u003C\u002Fp>\n\u003Cp>区域则是包含段落的一片区域。\u003C\u002Fp>\n\u003Cp>选区使用两个点来表示，每个点由段落和索引和文本的偏移量来表示。\u003C\u002Fp>\n\u003Cp>这个模型的好处是当且仅当两个模型相同的时候，可视空间才会相同，模型的任何变更都会很好地映射到可视空间（well-defined）。\u003C\u002Fp>\n\u003Cp>2 DOM到模型的映射\u003C\u002Fp>\n\u003Cp>分为内部映射和外部映射。内部映射是DOM和模型的映射，我们希望是一对一的。外部映射是当我们拿到粘贴的内容时，需要将内容映射到我们的段落-区块模型。我们希望外部映射是有损的，首先处理纯文本，然后是粗体\u002F任何\u002F链接等标记，接下来是图片和其它的格式 。\u003C\u002Fp>\n\u003Cp>将模型映射到DOM看起来类似这样：\u003C\u002Fp>\n\u003Cpre>\u003Ccode><div> <!-- root -->\n  <section> <!-- section -->\n    <!-- section-inner -->\n    <div class="section-inner layout-column">\n      <p>  <!-- paragraph -->\n        <strong><em>Baggins<\u002Fem><\u002Fstrong> <!-- text -->\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>【省略一段解释对应关系的，注释中都有写了。】\u003C\u002Fp>\n\u003Cp>映射样式的时候，我们会按顺序进行：首先是A，然后STRONG，然后EM，绝不会出现A在STRONG中的情况。\u003C\u002Fp>\n\u003Cp>3 编辑操作\u003C\u002Fp>\n\u003Cp>定义了6种操作：添加段落、移除段落、更新段落、添加选区、移除选区、更新选区。\u003C\u002Fp>\n\u003Cp>所有的编辑操作都可以由这6种操作进行组合而来。在这些操作下，所有的内容都是结构良好的。这些操作直接对应我们模型的变更，而不是DOM的变更 。\u003C\u002Fp>\n\u003Cp>4 捕获编辑动作\u003C\u002Fp>\n\u003Cp>键盘和鼠标操作被映射到这6种操作中，具体而言是从ContentEditable操作中映射而来：换行（enter\u002Fctrl-m）、删除（delete\u002Fbackspace）、输入、粘贴等。我们捕获这些事件，然后阻止它们的默认动作，然后将这些动作转换成内部的编辑操作。\u003C\u002Fp>\n\u003Cp>对其它的键盘事件，我们不阻止默认动作，而是让ContentEditor进行操作，然后在事件结束后将段落和DOM再映射回模型。\u003C\u002Fp>\n\u003Cp>如果每次模型变更都全量更新DOM，编辑体验会很差，因为内容在不停闪烁。我们监听了模型的变更，尽量让DOM的变化最小化。\u003C\u002Fp>\n\u003Cp>。。。分隔线。。。\u003C\u002Fp>\n\u003Cp>【展望未来的富文本编辑器，略，都是没影的东西。】\u003C\u002Fp>\n","\u003Cp>知乎看到一个问题，《为什么都说富文本编辑器是天坑》。里面的答案挺有意思的，各位做web前端的大牛们都有自己的切肤之痛。有兴趣的可以手工复制以下网址查看：\u003C\u002Fp>\n\u003Cp>\u003Ca href=\"https:\u002F\u002Fwww.zhihu.com\u002Fquestion\u002F38699645\u002Fanswer\u002F108376836\">https:\u002F\u002Fwww.zhihu.com\u002Fquestion\u002F38699645\u002Fanswer\u002F108376836\u003C\u002Fa>\u003C\u002Fp>\n\u003Cp>但是这些答案大部分还是停留在碰到的问题上面，而没有去深入总结和思考富文本编辑器背后的需求和实现思路。正好前两年在medium上看到一篇文章，叫《Why ContentEditable is Terrible》，推荐给大家。原文可点击左下角链接查看。\u003C\u002Fp>\n\u003Cp>\u003Ca href=\"https:\u002F\u002Fmedium.engineering\u002Fwhy-contenteditable-is-terrible-122d8a40e480\">https:\u002F\u002Fmedium.engineering\u002Fwhy-contenteditable-is-terrible-122d8a40e480\u003C\u002Fa>\u003C\u002Fp>\n","",{"total":15,"totalRoots":15,"comments":22,"pv":15},[]]