-
Notifications
You must be signed in to change notification settings - Fork 12
Introduction
⚠⚠ ⚠⚠ ⚠⚠
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.
(tl;dr) This is about CKEditor 5, the next generation editing solution for web applications.
CKEditor has come a long way in more than 11 years of its existence. During this time, it was greatly improved in many aspects, becoming a rock-solid solution for web applications.
The Web itself changed during these years. New standards emerged together with new ways to consume information and share it. A much stronger understanding about the value of web content has developed, for the benefit of the present and the future of the world. JavaScript finally showed its power in the everyday life of people and the web technology evolved to become the first mandatory option for modern software.
All the above fostered the creation of our current solution, CKEditor 4. It's a modern and powerful application, a clear innovation leader in the web editing environment. Still we think that a drastic move is necessary, to efficiently fulfill the expectations the world has today and in the future from us. That's all about CKEditor 5, in fact.
(tl;dr) To keep leading on innovation. Everything is to be re-thought.
CKEditor 5 represents a strong change in both strategy and design. The entire application is to be rethought in every single aspect and a new proposal that satisfies the current and future needs of our community is to be put in place.
While CKEditor 4 is a great solution, we feel that it has limitations that at times make our goals hard to achieve. At the same time, it is still way too connected to problems of the past, which in any case are still current, but we would like to change our position and think about current problems that will shape the future.
Still CKEditor 4 is a great piece of code and contains lots of innovative features. We understand that a good part of its code will be ported to CKEditor 5, but at the same time we'll review every single byte coming from it, cleaning it up and changing what needs to be changed.
(tl;dr) Focus mainly on UI rendering, download and initial loading.
CKEditor is not a performance intensive application. Still there are a few aspects that required attention, to bring a better overall user experience:
-
UI rendering must be fast and react naturally to user actions. This includes panels, dialogs, pop-outs, balloons, etc.
-
Initial loading must be fast. The editor must be ready to use in a blink.
-
Commands must execute fast.
-
Download performance must be optimized and smart download solutions must be considered, to reduce its impact on the overall page load.
There is still a lot of attention from our users regarding the last point, so we must understand what the possibilities to have less bytes to download are, keeping the same quality (the tricky part).
(tl;dr) Targeting browsers and apps in desktop, tablets and smartphones.
It's no news that CKEditor 5 is targeted to desktop workstations and notebooks, widely supported by its predecessor. No news as well that the world changed and that the Web is now delivered to an enormous range of different devices, from tablets, to smartphones, to washing machines. Even hybrid solutions are provided, like mixed tablet-notebooks.
While we're not focused on washing machines (yet!), tablets and smartphones are definitely of our interest, including their hybrid variations.
(tl;dr) A solution for compatibility with CKEditor 4 must be in place. Either API alignment, upgrade tools or documentation. On the other hand, features don't have to be ported 1:1 and some may even be missing.
It must be taken into consideration that the market has already many solutions incorporating CKEditor. Therefore our community expects to have a solid long term solution from us, counting on upgrading being a doable and manageable task.
While CKEditor 5 will come as a significant rewrite of the existing code and proposal, a solution for backwards compatibility with CKEditor 4 must be available. The solution doesn't necessarily have to fit the xcopy approach. It can also be a set of tools and documentation that guide developers on how to proceed with upgrading their installations. This touches both editor creation code and custom plugins.
The goal is making CKEditor 4 to 5 upgrading as simple "as possible".
When it comes to features, we're not planning to have a one-to-one alignment between CKEditor 4 and 5. In fact, we'll be taking the opportunity to reduce the API, the number of features and configuration options, so we can make things simpler. We would also like to deprecate features that don't fit any more in the modern Web, or that bring little to no effective benefit to our users.