Architecture Overview

Unlike version 4, CKEditor 5 will not be made of a single codebase anymore. We can define logical separation into 5 different sets of components and physical separation of the code into npm packages.

Logically, the project will consist of:

• CKEditor Library: the heart of the project. A generic library for editing.
• CKEditor UI Library: a reusable set of UI elements targeted to editing solutions.
• Themes: TODO.
• Features: modules bringing features to CKEditor, based on the library API.
• Creators: different editing solutions ready to be used, making use of the above building blocks.

At the same time, the project will also be split physically into multiple npm packages, each fulfilling one or more of the above roles. It's recommended that each package is kept in a separate Git repository.

The main Git repositories are described in the Repositories article.

The CKEditor 5 package names should be prefixed with ckeditor5-* and they should fall into one of the below categories:

• ckeditor5 – the main CKEditor 5 package.
• ckeditor5-core – the CKEditor 5 API.
• ckeditor5-ui-* – packages implementing the UI library (called also UI components), e.g. the default UI library – ckeditor5-ui-default.
• ckeditor5-theme-* – packages containing themes, e.g. the ckeditor5-theme-base theme.
• ckeditor5-creator-* – packages containing creators, e.g ckeditor5-creator-classic and ckeditor5-creator-inline.
• ckeditor5-* – all other packages containing features and additional tool libraries, e.g. ckeditor5-link.

As mentioned above, it is possible that a single package falls into more than one logical category. However, it's recommended that each package served one role.

The CKEditor Library

The CKEditor library is a general use API designed for building editing solutions inside browsers. It contains all the tools needed to create a stable and full-featured editing experience.

The library is made of the following main building blocks:

• Core: the basic elements of the API.
• Editing: the elements that enable and control the editing experience.
• Data: data input, output, manipulation and filtering.
• Tools: generic API tools.
• Bindings: integration with external code and everything about gluing things together into editing implementations.

Important note: While being a generic solution, the CKEditor Library is designed and optimized for CKEditor implementations, so third-party requirements may not be taken into consideration.

The CKEditor UI Library

(tl;dr) The default UI library used by CKEditor, which can be replaced by third-party libraries.

CKEditor 5 will introduce a UI abstraction level that will permit to have different UI libraries attached to the same editing solution. For instance, if an editor based on jQuery UI is to be designed, it should be possible to take the existing editing implementations and replace their existing UI components with jQuery UI elements.

While this flexibility is awesome, still a non-third-party solution needs to be in place, to avoid dependencies on specific projects. Therefore, the CKEditor UI Library will be introduced, including the default UI used by CKEditor.

While CKEditor will be a general purpose library, the CKEditor UI Library will be, in any case, optimized exclusively for the CKEditor needs. Therefore, even if it could be used by other projects, there is little chance that we’ll bring features and enhancements to it, if such features will have no use for the CKEditor project purposes.

Examples of UI elements available in the CKEditor UI Library:

• Toolbar
• Button
• Drop-down list
• Menu
• Menu button
• Dialog window
• Dialog window fields
• etc.

The main editor structure styling should be a part of the library as well.

Mobile

There is a good chance that the CKEditor UI Library will have its mobile variant which will include UI elements dedicated to mobile interfaces. This aspect will be better understood as soon as we conclude the design of CKEditor for Mobile.

Skins

When it comes to skins, it is quite dependent on the UI library in use. Therefore, the entire concept of skins will be delivered by the UI library itself, which will define if and how skins can be managed.

Features

(tl;dr) Plugins have the role of bringing features. In the first stage we may expect features dedicated to create good quality web content.

While we are in any case performing a significant review in terms of architecture and design of the project, plugins will keep the conceptual role they have in CKEditor 4: to bring features to CKEditor. In fact, the CKEditor Library alone has little use without plugins (and other building blocks of CKEditor, of course).

Unlike we did when creating version 4, this time we’ll not port all available plugins to CKEditor 5. Especially in the way we did it, without touching their code too much, leaving it mostly "as is". Instead, we’ll analyse which features to port and review them from scratch, especially in terms of design.

This means that we may have some features simplified, ported partially or even not ported at all.

What to Expect

The list of features to be ported to CKEditor 5 is still to be defined. We’ll definitely be focused on the most wanted features and on those that can enhance the quality of content created. We can also expect new features to come.

In fact quality of content is the key here and we must keep in mind that CKEditor has an important role. We must support the effort made out there to create good content for the Web and the future. This may be difficult in some situations, because many times people simply don’t have enough knowledge about content management and pretend to have things in a different way.

It is way too easy to introduce features that are attractive to the eyes of end users, but very bad for the quality of the content. For example, features that are dedicated to text formatting, like margins, borders, colors, fonts, alignments, etc. Those are the kinds of features that should be avoided and therefore they’ll not be our priority, at least in the first stage.

In any case, let’s also keep in mind that still a good part of our users want to have formatting features (no matter what). Additionally, CKEditor can be built to be a “word processor”, where no web content rules apply. Therefore the possibility of having quality formatting features also made available is not out of question.

Implementations

(tl;dr) Implementations are the final products delivered to end-developers. We should expect current classic and inline editors to be available, along with new solutions. There must be cross-compatibility for data produced with different implementations on the same configurations/systems.

Implementations represent the final product of the entire CKEditor project. They make use of the previously described building blocks (CKEditor Library, UI and plugins), bringing to light the editing solutions to be used by developers inside their applications.

The following are some sample implementation solutions:

• The normal editing box we offer today (classic editor).
• Floating toolbar for inline editing (inline editor).
• One line field editing.
• Top toolbar for whole page editing.
• Dedicated UI for mobile editing.
• Paged-like document editing (e.g. A4 pages).
• UI based on external libraries, like YUI and jQuery UI.
• Component for editing to be used in mobile or desktop apps.

Cross-Implementation Compatibility

There are situations when the same application may make use of more than one implementation of CKEditor. For example, it may use the classic editor for desktop and the mobile editor for mobiles, both accessing the same content base, which includes cross-editing of the same content on different devices (and therefore, different editor implementations).

Because of the above, special attention must be paid to the following aspects when designing editor implementations:

• Configuration: Whenever possible, configurations should be active for different implementations, each one behaving in the most appropriate way for its goal.

• Features: Whenever possible, features should be available cross-implementation. It’s acceptable though to have features that are not enabled in some cases.

• Data: Even if features are disabled, data produced with a different implementation sharing the same configuration should be preserved and remain untouched. In other words, if one just loads the same data in different implementations, no data loss is noticed. It is OK to have a part of the data not editable in an implementation that is not able to edit such part.