We would like to announce that the second alpha release of CKEditor 5 has just been published. This release follows the first alpha version and contains mainly bug fixes and minor improvements. The team is now focused on bigger changes which require more time to be concluded, however, some important ones made it to this release.
# CKEditor 5 features survey!
However, before we talk about this release, we would like to encourage all CKEditor 5 early adopters to take part in the survey to tell us which features are important to your use cases. Your feedback is extremely important and will help us decide on the must-have features and their prioritization in the CKEditor 5 development.
# UI library improvements
The “UI improvements” epic describes potential tickets that we want to work on in a near future. From it, 3 topics are our priority:
View#render()(a major simplification of the UI framework),
- dropping SASS (and introducing PostCSS),
- the feature cleanup.
The first topic was closed in this release and brings significant breaking changes. We decided to remove the
View#element getter’s behavior which made it render the view automatically on the first access. Too much magic in there lead to a lot of confusion. We replaced it with an explicit
View#render() method which also allowed us to remove the
View#init() method. All that (and some other improvements which we did on the way there) significantly simplified the UI framework and existing components. You can read more in the pull request and in the updated documentation.
Right now, we are working on dropping SASS because the lack of the “import once” feature turned out to be a deal breaker for CKEditor 5. We hope to replace it with PostCSS which not only seemed to support a proper “import once” mechanism but also will remove the dependency on the heavy
node-sass. Unfortunately, after a promising beginning, it turned out that the combination of webpack and PostCSS is not flawless, so the final solution will not be as perfect as we would like it to be. However, we still believe that the outcome will be really positive.
# Bug fixes
In total we fixed around 20 bugs, from which these are most important:
- An inline filler will not be injected into a widget anymore ( #1170).
- When content is pasted from Microsoft Word, the editor will choose HTML over the image (a screenshot of the content) which is in the clipboard (#653). This does not mean that pasting from Word works great now, but at least now a text is pasted and not a screenshot of it.
- [Edge] Ctrl+K will correctly move focus to the link balloon (instead of opening another tab) (#154).
- Ctrl+A pressed when a widget is selected will correctly select the editor content (#465).
- Collaborative editing scenarios with two users merging blocks and conflicting merge operations will now work correctly (#1161 and #1159).
- The first list item will now be correctly turned into a paragraph when pressing Backspace (#68).
- CKEditor 5 translation service will work correctly in
@ckeditor/ckeditor5-build-*repositories and on Windows #302 and #297).
# Other improvements
- We started using webpack 3 which allowed us to shave off ~10% from builds’ size (#475).
- A new CKEditor Cloud Services integration layer was introduced for CKEditor 5 which allowed us to handle sessions longer than 24h (yep, they happen 😃) (#7).
- Component factory (where button, dropdowns, etc. factories are stored) was made case insensitive to make it easier for developers to configure the editor (#324).
- Thanks to the Error codes page to which we link from all CKEditor 5 errors logged to the console, we were able to analyze the most frequent errors and improve their descriptions or to prevent them (e.g. by making the component factory case insensitive).
- We replaced gulp with npm scripts in the development environment (making it lighter and faster, for both the developers and CI) (#473).
- Observable properties are now marked in the API documentation (#285).
- The release tool was made significantly safer (which is important when you release ~30 packages) (#272).
# What’s next?
We are now focused on critical cleanup and refactoring which will allow us to stabilize the API (at least to a certain degree). The main topics are described in these three tickets:
At the same time, we are working on a couple of text and block formatting features. While not a part of the “semantic web”, they are very frequently required in real-life use cases. Besides, we use this occasion to define them in a more organized and cleaner way:
PS. Did I mention that we began working on the table feature?
For a detailed list of changes go to
firstname.lastname@example.org where you can check each package’s changelog.
Last but not least, we are getting an enormous amount of feedback on all possible channels (mainly on GitHub). The sooner we learn about your use cases, the more we can adjust CKEditor 5 to handle them, so do not hesitate to let us know what you think about our work!
Don’t forget about the CKEditor 5 features survey and you are most welcome to discuss the new features we are working on in relevant GitHub repositories. Thank you for your help!