We would like to let you know that the 5th developer preview of CKEditor 5 has just been tagged as version v0.5.0.
You can read about the initial goals of this iteration in the Planning: Iteration 5. While this release did not introduce many end-user features and bug fixes, it brought or began important improvements for the developers and resulted in closing 136 tickets.
As planned, the base image feature landed on master in this iteration. Its development is taking a significant amount of time (it took us already two iterations) because we are concurrently working on the widget system (read about the widgets concept in CKEditor 4 documentation).
So far we have got the following pieces ready:
We are now working on completing the keyboard support and will then work on captioning and alignment.
The following changes were introduced to engine and typing in this iteration:
We added custom copy/cut support for the clipboard feature. It is important to have full control over what gets to the clipboard when dealing with rich content (like e.g. widgets) and browser quirks.
This feature required implementing a generic
getSelectedContent() algorithm first.
We performed a major review and refactoring of the UI framework and library. It allowed us to significantly simplify the code, shave off a couple of kilobytes and, first of all, improve the developer experience. It is best summarized by these two tickets: ckeditor/ckeditor5-ui#95 and ckeditor/ckeditor5-ui#90.
This was probably the most important change in this iteration. While it had little visible effect, the changes significantly improved our testing and review processes.
First of all, we dropped our custom test runner and switched to Karma + Webpack. It improved the tests performance and general experience when working with bigger pieces of our extensive tests suite that overshadowed less convenient workflow with TDD.
However, the main goal was to simplify the introduction of Travis to all our packages:
Together with each CKEditor 5 package's 100% code coverage (including code branches) and integration with GitHub PRs it speeds up reviews and allows us to maintain the desired quality.
Last but not least, we are constantly working on the API documentation. From the beginning we have been thoroughly documenting our code, however, we have not made a definite choice regarding the documentation generator.
We have tested a couple of API documentation generators and decided to stick to JSDoc, which is still the most mature and extensible solution. We developed a set of JSDoc plugins which allowed us to write CKEditor 5 API documentation in a simpler and more maintainable way. For instance, we added link and type references validation as well as better support for ES6 classes and modules. The results are satisfying enough and we are now reformatting our API docs to the new format. We will share our solution with the JSDoc community once it stabilizes.
Later on, we will also have to work on a more developer-friendly theme (or in fact — an entire page generator) which will close the gap between JSDoc and what JSDuck offers.
We updated the basic CKEditor 5 sample that you can play with. Check out the developer preview of CKEditor 5 (version 0.5.0) on the CKEditor 5 GitHub.io page.
Iterantion 6 has already started. We will continue working on the image feature (keyboard support, captioning and alignment), content filtering stability and blockquote support.
We are most excited about the project and would love to get some feedback about this early preview.
You can report all general issues in the main CKEditor 5 repository. Specific issues, like those related to the editing engine, should be reported in their respective repositories. Very general ideas and questions can be reported in the design repository.