CKEditor 5：富文本编辑器的未来

ckeditor 已经存在 12 年之久，在这期间，它在很多方面都做了改进，成为一个稳健的 web 应用解决方案，目前下载量已经达到 15 million downloads 。

web 本身也在改变，新的标准和信息分享的新方法伴随出现，当前利益和世界未来都驱使我们为断考虑 web内容的价值。最终 javascript 展现了它的威力，在人们的日常生活中它无处不在，已经成了流行软件的标准选项。

所有上述现象共同形成了当前的解决方案，ckeditor 4，它是一个强大的流行应用，web 编辑器领域无争议的创新领导者。但我们仍然相信，需要更巨烈的变革来满足世界对我们当前和未来的期待。

事实上，这就是 ckeditor 5 要做的。

ckeditor 5 在策略和设计上都有大的改变。整个应用将重新考虑每一个方面和每一个建议，以期满足社区当前和未来的需求。

尽管 ckeditor 4 是一个伟大的解决方案，我们仍然觉得他有一些局限导致我们的目标难以实现。同时它在过去还产生了很多问题（当前依然存在），所以我们想改变这个局面，将这些问题放到未来这个背景下来考虑。

ckeditor 4 依然是很棒的代码，有很多创新的功能（像 widgets, content filtering, magicline 和 accessibility checker).。一方面我们要将好的代码引入到 ckeditor 5，但同时我们检查从它而来的每一段代码，清理干净，并根据需要做出修改。

我们已经在ckeditor 4中实现了通常意义的高层分离，例如极其的易用性，全球化，可配置性和可定制性。这里是一些其他更突出的特点。

ckeditor 不是一个性能密集型的应用，但是仍然有一点需要注意的地方来提高整体的用户体验：:

必须优化下载性能，找一个有效的下载方案来减少整体页面加载的影响。

尽管文档写得很好很清晰，但 ckeditor 4 的代码没有引入一些流行的编程实践。

ckeditor 5 会做出以下改进:

多终端支持

支持桌面，平板，智能手机上的浏览器和app.

ckeditor 5 支持桌面和笔记本电脑已经不是新闻，它的前任已经支持得很广泛了。 世界上的一些变化也已经不是新闻，现在web是由多终端组成的，从平板到智能手机，到洗衣机，甚至混合方案，如平板加笔记本。

尽管我们不关注洗衣机，但平板和智能手机肯定是我们感兴趣的，包括他们的混合方式。

更多信息参见： browser compatibility

这也一直是 ckeditor 最重要的差异化因素。我们写代码注重质量。这意味着我们一直致力于书写经过广泛测试的代码，依照同行审查来合并代码，利用自动化来确认关键质量方面的问题，只有经过有力的测试过程才发布。所有这些都遵循开放式设计的方法，经过多人协作。

html 是 web 的语言。因此，可以很自然地假设 web 内容应该用这种格式呈现。ckeditor 4 已经这样做了，它的功能基于 html 构建，直接修改呈现内容的 dom。

但是 html 有自己的意图和局限。考虑到更语义化的值、高级编程功能和无需内置视觉兼容措施，我们需要更好的数据格式。ckeditor 5 中，我们最终提出一个自定义 javascript 数据模型，并有强大的 api 来操作它。该数据模型加入了一个典型的 mvc 解决方案，该方案中的视图——呈现给用户的可编辑的文档 —— 只是当前用户上下文中数据的简单 html 展现。

该数据模型被设计为在 ckeditor 中启用操作转换 (ot)。 这项技术将是一个进步，使得进一步创新成为可能。

我们的定制数据模型 api 是一个复杂的系统，当我写下这句话的时候，这个系统正在完善代码和文档。为了更好的展示它的好处，让我来指出一些新的即将公开的功能：

尽管 ckeditor 4 被设计为能够处理不同于 html 的数据格式，在 ckeditor 5 中这一点将更为明显。从一开始它就被设计为能有效支持所有格式，从 markdown (或 commonmark), 到 wiki markup， 到 rtf, 到许多其他格式。从一开始我们就应该期待针对所有这些不同案例的可用方案。

contenteditable 被认为是有害的，但同时也是在 web 上启用富文本编辑的唯一正常的方式 。在开发 ckeditor 4 的过程中我们发现，我们一步步地重写了越来越多的不令我们满意的原生特性。我们控制回车键，给操作加样式，粘贴，剪切，拖放等。这给了我们和开发者对编辑器行为的控制。然而，有些功能比如输入、ime、原生自动完成无法用javascript控制。其他的功能（比如插入符号的移动）非常难以实现，因此我们必须使用 contenteditable.

新的数据模型如何适应它？ 除了需要原生处理的操作，所有操作都会直接在新的数据模型上通过 ckeditor 插件实现。对模型的改动会自动传递到 dom。比如，回车键将会被实现为“在当前插入符号的位置分割当前区块”。一旦插件修改了数据模型，视图（dom）也会被修改。

一些需要本地处理的功能（类似打字）将会通过在 dom 上的变化进行观测，将更改传到数据模型上进行操作。模型也能拒绝这样的变化（如果他们违反它的一些规则），并且这些恢复操作将传到 dom 上来修复它。

这种模型（contenteditable 处理输入和选择相关的功能，其余的则在 javascript 中处理）这一直是由 w3c 工作组编辑的。在“fixing contenteditable”上，你可以阅读到更多 contenteditable 的未来。