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.
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.
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).
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:
For a detailed list of changes go to ckeditor5@v1.0.0-alpha.2 where you can check each package's changelog.
Thanks!
Last but not least, we are getting an enormous amount of feedback on all possible channels (mainly on GitHub and Gitter) for which we are extremely grateful. 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!
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.
Take the CKEditor 5 features survey!
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),The first topic was closed in this release and brings significant breaking changes. We decided to remove the
View#elementgetter'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 explicitView#render()method which also allowed us to remove theView#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:
@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:
Finally, we began designing a new theme for CKEditor 5 (which will also be shared with Letters) and we will soon make it trivial to change the CKEditor 5 UI language (in runtime).
PS. Did I mention that we began working on the table feature?
Samples
Check out the Examples section in the documentation. You can also find some more examples in the Features section.
Changelogs
For a detailed list of changes go to
ckeditor5@v1.0.0-alpha.2where you can check each package's changelog.Thanks!
Last but not least, we are getting an enormous amount of feedback on all possible channels (mainly on GitHub and Gitter) for which we are extremely grateful. 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!