| 分类
编辑器目前可以分为以下三类：
-
textArea 远古时代的编辑器实现，起始阶段，最简单的如多行文本
-
contentEditable 浏览器提供了基础功能
- draftjs (react)
- quilljs (vue)
- prosemirror(util)
-
脱离浏览器自带编辑能力，独立做光标和排版引擎
- ffice 、wps、 google doc
其中第一类不支持图片及视频等其它内容，第三类可能是一项浩大的工程，目前活跃的开源代码框架大多属于第二类。
| 发展历程
在整个发展过程中，富文本编辑器遇到过一些困境。也正是因为这些困境，可以将发展历程分为L0、L1、L2和L3阶段。
L0->L1
L0，即初代的富文本编辑器，依赖于浏览器自身的execCommand，仅提供了有限的命令，实现最简单的功能。 随着对样式越来越丰富的要求，此时的富文本编辑器无法满足需求，L1阶段的编辑器应运而生。 L1的富文本编辑器采用 自定义execCommand的方案，可以实现更加丰富的富文本功能。
L1->L2
L0、L1的富文本编辑器，仍然都是通过execCommand修改HTML。而不同浏览器中，对于同一表象的富文本，其HTML结构可能大不相同。 比如说 加粗 ，其HTML可能是加粗，可能是加粗，也可能是加粗等等。
为了解决数据与视图无法一一对应的问题，提出了自定义数据模型的概念。
自定义数据模型， 是富文本编辑器在富文本HTML-DOM树的基础上抽离出来的数据结构，相同的数据结构可以保证渲染的HTML也是相同的。自定义的命令直接控制数据模型，最终保证渲染的HTML文档的一致性。
对于相同的HTML，不同的富文本编辑器最终呈现的数据模型并不相同.
L2阶段的富文本编辑器，通过抽离数据模型，解决了富文本中脏数据、复杂功能难以实现的问题。通过数据驱动，可以更好的满足定制功能、跨端解析、在线协作等需求。
L2→L3
到L2阶段的编辑器，可以满足绝大部分的使用场景。那为什么后面又发展出L3呢？
这是因为，L0-L2的富文本编辑器都是基于浏览器的contentEditable，在修改数据模型时，往往需要对用户操作进行拦截
对用户行为进行拦截是很难控制的，再加上不同浏览器的兼容问题，很容易出现bug
为了解决contentEditable编辑不可控的问题，以 Google Docs 为代表的编辑器通过“自研排版引擎”步入了L3阶段
自研排版引擎，彻底抛弃了contentEditable，通过自行控制光标位置、选区绘制、排版、监听输入等行为，实现和浏览器相似的编辑效果。“自研”，无疑具备了更高的扩展性
但与此相对应的，其开发难度高、成本高、隐性问题多，在整体体验和性能上与原生浏览器渲染仍存在一定差距，该阶段的编辑器还有一段路要走。
| 常用富文本编辑器
| 名称 | start | 功能 |
|---|---|---|
| tinymce | ✨ 5779 | 网络图片／视频、history |
| wangEditor | ✨ 5905 | images本地和网络、video 需网络、history、Tables、emojis；可用于 React／Vue／angular；移动端已暂停维护 |
| 百度UEditor | ✨ 3923 | 功能齐全，样式较旧；语言：jQuery |
| CKEditor | ✨ 1416 | history、图片本地、无视频； |
| KindEditor | ✨ 1314 | 展久功能齐全，样式较旧 |
| MediumEditor | ✨ 12791 | 28KB gzip；Browser Support：good；炫酷简介外观；支持：Extensions & Plugins （Images and Media embeds, Tables and Markdown）；可视化较好但Media需输入url；语言：jQuery |
| Simditor | ✨ 4025 | 网络图片、无视频、Extensions（emojis、markdown、fullscreen等）；语言：jQuery |
| Summernote | ✨ 7789 | Browser Support：firefox、chrome、IE;支持：images本地和网络、video 需网络；语言：jQuery |
| Quill | ✨19961 | Browser Support：good；支持：多平台（平板、手机、PC）；对应 vue 版本：vue-quill-editor☆ 2943；支持：本地图片、网络视频、服务端渲染和单页应用、可自定义或可扩展 |
| Slate | ✨ 9262 | 39.3KB gzip；文档齐全；支持：images／video（输入url）、emojis、search-highlighting、markdown、history、部分插件；框架：React |
| HandyEditor | ✨ 6 | 移动端和pc端自适应、history、网络图片、无视频、emojis |
如何技术选型？
没有编辑器研发团队：推荐基于 CKEditor 4、TinyMCE、wangEditor 二次开发
有几人编辑器研发团队：推荐自研 L0 ~ L1 传统模式编辑器
有几十人编辑器研发团队 & 需要个性化排版：推荐自研 L3编辑器
| 困境
现今主流的 Web 富文本编辑器，大多都是基于 contenteditable 开发的。
1. contenteditable带来的问题
视觉内容（用户所见）与实际内容（DOM）的一对多关系
即看上去一样的文本内容，却可能对应了多种 DOM 结构
例如下面这段文字：
The hobbit was a very well-to-do hobbit, and his name was Baggins.
描述这句话的 HTML 可以有多种：
视觉选区与实际选区的多对多关系
即视觉选区不同位置生成的DOM也是不同的 DOM 的处理存在兼容性问题
因此，对于相同的HTML，最终呈现的数据模型并不相同
contenteditable is terrible, 但是编辑器已经最小化了对它的使用
比之更为严峻的是，操作系统、浏览器、输入法相互组合形成的紊乱生态 —— 一个编辑器无法控制的，但产品又期望在上面开出繁花的生态
所以才说，Web 富文本编辑器是前端的天坑之一
2.富文本跨平台兼容问题
HTML 数据渲染在不同平台中可能出现的问题：
从上图中可以看出，HTML的优点是特性丰富，灵活多变。而正因如此，其很难严格的定义数据。 因此若是将HTML作为流转的数据，很容易在不同平台内出现解析兼容问题。
| 参考资料
# 从流行的编辑器架构聊聊富文本编辑器的困境
# 富文本编辑器之游戏角色升级ing
# 富文本及编辑器的跨平台方案
# 富文本编辑器的技术演进
