Implementations
⚠⚠ ⚠⚠ ⚠⚠
This wiki served in the early days of CKEditor 5 development and can be severely outdated.
Refer to the official CKEditor 5 documentation for up-to-date information.
Working Draft
Implementations represent the final product of the whole CKEditor project. They make use of the building blocks of CKEditor (CKEditor Library, UI and plugins), bringing to light the editing solutions to be used by developers inside their applications.
The following are implementations that we should take in consideration during the design of CKEditor 5:
- Classic Editor
- Inline Editor
- Single Line Editor
- Textfield-Like
- CKEditor for Mobile
- jQuery UI Editor
- Stack Overflow Editor
It may happen that some of them will not be fully developed, but still prototypes should be available so we can prove that the API and the overall CKEditor 5 implementation can satisfy their needs.
Other than a general description, the “design purpose” of each implementation is being explained, to underline what is the role of each case into the overall CKEditor 5 design.
This is the most widely used implementation of CKEditor and the one historically available since the very beginning of the project.
The classic editor is mainly used in web applications that are based on forms to be filled by end-users when creating and editing content.
Being this the implementation proposed during the whole lifetime of the project and also being it the most used case, it is simply mandatory for us to provide this in the very first stage of CKEditor 5.
The inline editor has been introduced with CKEditor 4. It allows editing specific elements in a web page, by displaying a floating toolbar attached to the editable elements.
Most of the web applications related to content creation have been designed during the past years based on forms. In these cases, the classic editor is definitely a better fit. Inline editing brings new design possibilities for applications and is now starting to be adopted. It allows for a much more dynamic and really contextual editing experience. It’s not the one and only solution, but paired with the classic editor it makes the editing experience complete.
Inline editing is an innovative solution and therefore must be available. It is present on CKEditor 4, so it is a must have. Additionally, it is a use case that is quite different than the classic editor, so it is worth having it to ensure that it is possible to have it.
An element that acts like a form field (styled similarly) but that can still have rich content.
The enter key should be configurable and it may have no action. The output should be either inline content (no enter key) or the usual block level content (with enter key).
The field should auto-grow with contents (may be configured to not wrap, if necessary).
The single line field is a simple editor for small content, for example titles, which could still have rich features like bold or linking.
This is not a strictly must-have use case, but it serves to the project because of two aspects:
- It is similar to inline editing, so many things on them are common.
- It is supposed to be a lighter editor.
Similar to the “Single Line Editor” implementation.
An input/textarea like field, but with some very limited rich-text (or not at all!) and no toolbar (like on Facebook or Twitter). This is very often related to autocompletion and "replace as you type". A textarea/input with some "flavor" (like automatic smileys, @nicks, etc.).
A simple input field where no formatting or rich-editing is expected, but still some special features are wanted. For example, a list of people appears when typing @nick names (e.g. Facebook).
This case is useful for the project to understand how to deal with situations where the editor should not produce formatted text but at the same time bring rich tools to the end user for better integration with the backend system.
All the above toolbar-based editors should have their mobile targeted counterparts that introduce the necessary usability aspects of mobiles into the same editing models they propose. This is especially true to the classic and inline implementations. Therefore, per se, CKEditor for Mobile is not a new editing model, but a repropose of the desktop models into mobile devices.
Current applications are moving to mobile. Either mobile only solutions are being proposed or, mainly, multi-device applications, which work on desktop, tablets and smartphones. CKEditor for Mobile is here for this, to make it possible for users to have a wonderful editing experience no matter the device they use.
Mobile is a key requirement for CKEditor 5, so this implementation is clearly our main effort towards this.
An editor based on CKEditor, but made of UI elements provided by jQuery UI. We should be able to provide all previous described editing models based on toolbars, having just their UI replaced.
Additionally, there should be some level of API integration offered into the native format used by this library.
There are several applications based on third-party libraries. Developers of these systems would be happy to have a solution that seamlessly integrates with the code they already use today.
It should be possible for third-party development groups to develop their own editing solution based on CKEditor. We’re choosing these two popular libraries as showcases for this feature.
A browser extension/add-on that replaces the Stack Overflow textarea-based editor with a CKEditor classic editor especially customized for it.
Stack Overflow users are required to use markdown when writing their content. This is both cumbersome and easy to make mistakes. Replacing this with a true WYSIWYG editor will facilitate their lifes.
This implementation have the following scope:
- Distribute CKEditor inside a non pure web-application (browser extension).
- Being able to replace third-party applications solutions with CKEditor.
- Being able to handle non-html data (markdown).