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 的過程中我們發現，我們一步步地重寫了越來越多的不令我們滿意的原生特性。我們控制Enter鍵，給操作加樣式，粘貼，剪切，拖放等。這給了我們和開發者對編輯器行為的控制。然而，有些功能比如輸入、ime、原生自動完成無法用javascript控制。其他的功能（比如插入符号的移動）非常難以實作，是以我們必須使用 contenteditable.

新的資料模型如何适應它？ 除了需要原生處理的操作，所有操作都會直接在新的資料模型上通過 ckeditor 插件實作。對模型的改動會自動傳遞到 dom。比如，Enter鍵将會被實作為“在目前插入符号的位置分割目前區塊”。一旦插件修改了資料模型，視圖（dom）也會被修改。

一些需要本地處理的功能（類似打字）将會通過在 dom 上的變化進行觀測，将更改傳到資料模型上進行操作。模型也能拒絕這樣的變化（如果他們違反它的一些規則），并且這些恢複操作将傳到 dom 上來修複它。

這種模型（contenteditable 處理輸入和選擇相關的功能，其餘的則在 javascript 中處理）這一直是由 w3c 工作組編輯的。在“fixing contenteditable”上，你可以閱讀到更多 contenteditable 的未來。