CKEditor 已经存在 12 年之久，在这期间，它在很多方面都做了改进，成为一个稳健的 web 应用解决方案，目前下载量已经达到 15 million downloads 。
Web 本身也在改变，新的标准和信息分享的新方法伴随出现，当前利益和世界未来都驱使我们为断考虑 web内容的价值。最终 JavaScript 展现了它的威力，在人们的日常生活中它无处不在，已经成了流行软件的标准选项。
所有上述现象共同形成了当前的解决方案，CKEditor 4，它是一个强大的流行应用，web 编辑器领域无争议的创新领导者。但我们仍然相信，需要更巨烈的变革来满足世界对我们当前和未来的期待。
事实上，这就是 CKEditor 5 要做的。
为什么需要 CKEditor 5?
保持领先的创新都来自反思。
CKEditor 5 在策略和设计上都有大的改变。整个应用将重新考虑每一个方面和每一个建议，以期满足社区当前和未来的需求。
尽管 CKEditor 4 是一个伟大的解决方案，我们仍然觉得他有一些局限导致我们的目标难以实现。同时它在过去还产生了很多问题（当前依然存在），所以我们想改变这个局面，将这些问题放到未来这个背景下来考虑。
CKEditor 4 依然是很棒的代码，有很多创新的功能（像 widgets, content filtering, magicline 和 accessibility checker).。一方面我们要将好的代码引入到 CKEditor 5，但同时我们检查从它而来的每一段代码，清理干净，并根据需要做出修改。
需求
我们已经在CKEditor 4中实现了通常意义的高层分离，例如极其的易用性，全球化，可配置性和可定制性。这里是一些其他更突出的特点。
性能
主要在于UI的渲染，下载和初始化加载
CKEditor 不是一个性能密集型的应用，但是仍然有一点需要注意的地方来提高整体的用户体验：
UI渲染必须快速响应合理地用户动作。这包括面板，对话框，弹出窗户，信息提示，等等。
初始化加载必须快。编辑器必须在一瞬间准备好。
执行命令的速度必须快。
必须优化下载性能，找一个有效的下载方案来减少整体页面加载的影响。
现代化
基于ECS5和ES6编码，基于AMD和MVC模式，基于NPM分发。
尽管文档写得很好很清晰，但 CKEditor 4 的代码没有引入一些流行的编程实践。
CKEditor 5 会做出以下改进:
将代码按 AMD 模块分割.
清晰的 MVC 模式.
NPM 做为核心分发组件.
完整遵循 ES5 部分遵循 ES6 (Promises, classes, 等).
多终端支持
支持桌面，平板，智能手机上的浏览器和app.
CKEditor 5 支持桌面和笔记本电脑已经不是新闻，它的前任已经支持得很广泛了。 世界上的一些变化也已经不是新闻，现在web是由多终端组成的，从平板到智能手机，到洗衣机，甚至混合方案，如平板加笔记本。
尽管我们不关注洗衣机，但平板和智能手机肯定是我们感兴趣的，包括他们的混合方式。
更多信息参见： Browser Compatibility
质量
(概要) 按照CKEditor满足的严格的质量标准打造
这也一直是 CKEditor 最重要的差异化因素。我们写代码注重质量。这意味着我们一直致力于书写经过广泛测试的代码，依照同行审查来合并代码，利用自动化来确认关键质量方面的问题，只有经过有力的测试过程才发布。所有这些都遵循开放式设计的方法，经过多人协作。
新的数据模型
(概要) 针对编辑视图会有一个基于 MVC 模式的自定义 JavaScript 数据模型。它会集中在支持操作转换，该功能带来了激动人心的可能性。
HTML 是 Web 的语言。因此，可以很自然地假设 Web 内容应该用这种格式呈现。CKEditor 4 已经这样做了，它的功能基于 HTML 构建，直接修改呈现内容的 DOM。
但是 HTML 有自己的意图和局限。考虑到更语义化的值、高级编程功能和无需内置视觉兼容措施，我们需要更好的数据格式。CKEditor 5 中，我们最终提出一个自定义 JavaScript 数据模型，并有强大的 API 来操作它。该数据模型加入了一个典型的 MVC 解决方案，该方案中的视图——呈现给用户的可编辑的文档 —— 只是当前用户上下文中数据的简单 HTML 展现。
该数据模型被设计为在 CKEditor 中启用操作转换 (OT)。 这项技术将是一个进步，使得进一步创新成为可能。
新的可能性
(概要) 源自我们的自定义数据模型的一些功能示例：协作编辑、跟踪变化、更好的重做系统、强大的功能 API、RDFa 和注释。
我们的定制数据模型 API 是一个复杂的系统，当我写下这句话的时候，这个系统正在完善代码和文档。为了更好的展示它的好处，让我来指出一些新的即将公开的功能：
协同编辑：这是第一个 OT 带来的明显的好处，也是我们非常期待的功能。
追踪改变：完善的数据注解，与一个独立的视图模块一同，让富 UI 功能类似追踪改变。
更好的撤销/重做：OT 还有一个好处是精确地持有在数据上定义行为的可能性，这让系统拥有较好的性能和强大的撤销系统。
强大的API：从视图中解耦数据将会使得系统变得更简单，这也给 CKEditor 带来的更高级的功能。例如：使用富 UI 工具处理数据部分（类似 CKEditor 4工具，但是更好，更快）。
RDFa，注解：不同于视图的语义，拥有简单的注解介绍的功能，这在上一个版本更复杂。
Markdown, Wiki 标记及其他
(概要) 数据采用非HTML格式即将成为现实，超越以往任何时候。
尽管 CKEditor 4 被设计为能够处理不同于 HTML 的数据格式，在 CKEditor 5 中这一点将更为明显。从一开始它就被设计为能有效支持所有格式，从 Markdown (或 CommonMark), 到 Wiki Markup， 到 RTF, 到许多其他格式。从一开始我们就应该期待针对所有这些不同案例的可用方案。
ContentEditable 和新的数据模型
(概要) 在依然使用 contentEditable 来处理输入和选择的同时，所有功能将会直接在新的数据模型上开发。无需处理 DOM 怪异行为。
ContentEditable 被认为是有害的，但同时也是在 web 上启用富文本编辑的唯一正常的方式 。在开发 CKEditor 4 的过程中我们发现，我们一步步地重写了越来越多的不令我们满意的原生特性。我们控制回车键，给操作加样式，粘贴，剪切，拖放等。这给了我们和开发者对编辑器行为的控制。然而，有些功能比如输入、IME、原生自动完成无法用JavaScript控制。其他的功能（比如插入符号的移动）非常难以实现，因此我们必须使用 contentEditable.
新的数据模型如何适应它？ 除了需要原生处理的操作，所有操作都会直接在新的数据模型上通过 CKEditor 插件实现。对模型的改动会自动传递到 DOM。比如，回车键将会被实现为“在当前插入符号的位置分割当前区块”。一旦插件修改了数据模型，视图（DOM）也会被修改。
一些需要本地处理的功能（类似打字）将会通过在 DOM 上的变化进行观测，将更改传到数据模型上进行操作。模型也能拒绝这样的变化（如果他们违反它的一些规则），并且这些恢复操作将传到 DOM 上来修复它。
这种模型（contentEditable 处理输入和选择相关的功能，其余的则在 JavaScript 中处理）这一直是由 W3C 工作组编辑的。在“Fixing ContentEditable”上，你可以阅读到更多 contentEditable 的未来。
项目分割
(概要) 为了灵活性和更好的协作，将项目分割成几个主要部分
即使是基于插件的，CKEditor 4代码 一直集中在单个Github仓库。 在CKEditor 5中，项目将被分成关键的主要部分以获得额外的灵活性、易维护性和协作：
CKEditor 库：项目的核心。它是一个不限定编辑范围的通用库。
CKEditor 界面库: 一套致力于编辑解决方案的可重用界面元素。分离出这个库也可以使得实现完全自定义界面的编辑器成为可能，包括使用已存在的界面框架。
插件: 基于库API，为CKEditor提供功能
实现: 利用以上构造块的各种可用的编辑解决方案
查看 架构概述 获得更多详情。
Different Implementations
(概要) CKEditor 5 将会成为一个编辑库，上面可以发布针对各种需求的完美解决方案，从小而快到大型（速度也快！）的编辑需求。
一直到 CKEditor 4, 我们一直推荐两种主要的编辑格式：经典编辑器（带有工具条的编辑框）和内嵌编辑器（真实页面中内容上的浮动工具条）。这种方法已经满足大部分使用场景了，甚至一些创造性的解决方案也被开发出来了，如 Alloy Editor。
近年来，Web 已经抢占了桌面应用的市场。这推动了开发者给浏览器带来越来越多的高级解决方案。这影响了编辑内容的方式。
同时，web 开发变成了一个非常丰富的环境，有着成百上千的不同方法去解决问题，也有着广泛的不同需求。
考虑到这些，我们正在改变我们接近CKEditor5的脚步。我们将不再只有两个可用的解决方案，取而代之的将是一个编辑解决方案的框架。同时，我们将开发一些基于它的“开盒即用”的解决方案，这些将在许多不同的环境中使用。从小的功能到超先进的全功能应用，这将是一个真正“通用”的方法。
向后兼容
与 CKEditor4 兼容的解决方案必须到位，无论是 API、升级工具或者文档。另一方面，功能不必1:1的移植，有些甚至要去掉。
我们必须考虑市场上已经有成千上万的程序与 CKEditor 混淆。因此我们的社区期待推出一个坚实而长期的解决方案，使升级成为一个可行可管理的任务。
CKEditor 将会在现有代码上做出重要修改，包括一个新的 API 和一个向后兼容 CKEditor4 的解决方案。解决方案并不一定适合拷贝文件的方法，也可以是一组带有文档的工具，引导开发人员进行升级和安装。这同时涉及到了编辑器创建代码和自定义插件。
最终目标是让 CKEditor4 到 5 的升级变得尽可能简单。
功能兼容
说到功能，我们不打算一一对比 CKEditor 4 和 5 之间的不同。事实上，我们正抓住机会去简化 API、功能项和配置项，这样我们就可以吧事情简单化了。我们也要反对那些不适合现代网络或者不能给用户带来有效利益的功能。
开放资源
永远开放资源！
我们已经向大家提供开放源代码软件超过十年了。这是我们的理念中非常重要的观点并且没有什么能够改变这一点。这正是书写本文的原因。我们从未像今天这样开放。
何时何地
我们一直努力工作。没有规定日期，但 2016 年将会很热门。
CKEditor5 的工作开始于一年前。我们致力于开发一些在新的数据模型下的新的数据接口。到目前为止结果非常好，尽管还没有一个完全的编辑器样例。
在过去几个月里，我们开始强化对于 CKEditor5 的关注，投入更多的资源。该项目的许多方面仍处于设计阶段，所以这是你加入我们并提出想法和建议的最佳时机。CKEditor5 的设计库已经启动在 GitHub 上了。这是学习和讨论项目设计的中心点。其他相关的库也已经开始了，代码就在那里，快来加入我们吧。
我们不喜欢把项目的日期公布于世。这样会给团队带来不必要的压力，同时会带来一些不必须的期待。但我们估计 2016 将会是 CKEditor 5 之年。alphas 版会较早发布，接着是稳定版。
和它的前任一样，CKEditor 5 注定是引以为豪的成功开源软件。为了它的实现我们将全力以赴。我们期待你的支持。
