CKEditor 5：富文本編輯器的未來

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 注定是引以為豪的成功開源軟件。為了它的實現我們將全力以赴。我們期待你的支持。

請繼續關注。

感謝 CKSource。