CKEditor monthly for January, 2017
Goodbye 2016. Welcome 2017! From now on we will deliver compact monthly briefings with the latest updates on our progress with CKEditor and other related news. Find out what is the latest state of things for January 2017. Read on for more!
CKEditor in review
CKEditor 4.6.1 and 4.6.2 have been released as well as the latest (5th) developer preview of CKEditor 5.
This is the first minor release that follows the well-received CKEditor 4.6 and contains some bug fixes, including a noteworthy improvement in the Color Button plugin.
Read the full CKEditor 4.6.1 release blog post for more details.
The second "minor" release in the 4.6 line introduces two important features: a new default color palette for the color selector and yet another editor localization — Azerbaijani.
Read the full CKEditor 4.6.2 release blog post for more details.
We are currently working on another major release. CKEditor 4.7 will introduce some general improvements, but the focus point this time is enhancing the UX when it comes to working with tables. This means introducing custom selection handling inside CKEditor. The aim is to provide a nice highlighting experience for selected table parts across all major web browsers and enable rectangular selection within a table. Stay tuned!
After releasing the fifth CKEditor 5 Developer Preview (v0.5.0) we got busy with the next iteration.
Version 0.6.0 triggered various infrastructure issues which absorbed us so much that we decided to extend this iteration until the end of January. This could be a nice way of saying that we have a delay ;), but the changes that we have made and on which we are still working are really significant and could only be done before we release CKEditor 5 and could not be split into multiple iterations.
We are getting closer and closer to the final release, so it is high time to re-evaluate architectural decisions which we have taken earlier. This is especially important for the project infrastructure because all the software (which includes the official packages as well as 3rd party ones) is built upon it. Some of the topics which we (re)opened were:
- whether we want to keep the multi-repo architecture,
- how will we organize the issues,
- how are we going to implement translations,
- and finally, how are we going to release CKEditor packages?
However, the two most influential issues turned out to be a question whether we need the compilation step and how to switch to scoped packages and versioned dependencies.
Compilation was a building step performed before bundling CKEditor which was meant to encapsulate all CKEditor-specific tasks so that CKEditor could be later bundled using any bundler of choice. This was a noble idea but turned out to be really inconvenient and complicate things instead of simplifying them. We decided to get rid of the compilation step by aligning our building process as much as possible to the "JS standard(s)" (like there is one) and encapsulate the remaining things (such as language files compilation) in plugins prepared for existing bundlers.
Even now, the change required a lot of work, but we have already seen that it makes it a lot easier to integrate building CKEditor with your workflow.
After settling on the building without compilation, we turned our eyes towards switching to scoped packages and versioned dependencies. So far, we have been using npm to install dependencies from GitHub by using GitHub URLs in
package.json. We need to stop doing this and use proper versioned dependencies. We also want to have all the official packages scoped in
@ckeditor. This meant that we needed to review all our existing dev tools. We took that chance and proposed a simple (and generic) tool called mgit2. It allows to manage multi-repo projects and together with Lerna make a perfect pair for multi-repo multi-package projects.
We are now working on integrating mgit2 into our Travis setup. Once this is done, CKEditor 5 will be super easy to integrate, work with and develop.
After this lengthy introduction about infrastructure I will just list some of the other things that we worked on because, besides infrastructure, we are also constantly pushing forward features and improvements for CKEditor 5 itself.
- Translation service (already mentioned), is under development.
- Release tools are under development. They include automatic changelog generation, automated semantic version bumping (based on the changelog) and synchronising dependency versions.
- Keyboard support for widgets was improved (also ckeditor/ckeditor5-engine#696).
- Tooltips were added to buttons.
- The paragraph feature's converter behaves like a wildcard now, which is important for handling pasting content that contains markup with no existing converters.
- Image styles (a.k.a. alignment) were implemented.
- Editor and plugin events for initialisation steps were added.
- Rect utils were extracted from
BalloonPanelViewto enable code reuse.
- Delta transformation utils were implemented in order to allow processing other users changes.
- A wireframe theme was extracted from the Lark theme in order to allow building your own themes in an easier way.
- And many bugs were fixed
Around the Net
- A Standard for Rich-Text Data - an interesting proposal by CKEditor Project Lead and CKSource CEO regarding how to approach Rich-Text Data.
- The Great World of Open Web Standards - refreshing insight into HTML standard(s) by one of core CKEditor 4 developers.
- TYPO3 v8.5 released with CKEditor inside
- Some useful tips on creating a CKEditor plugin with Drupal 7 using WYSIWYG
- CKEditor Accessibility Checker in Drupal 7 - a Drupal sandbox module
- The following new plugins were added to the CKEditor Add-ons Repository:
We welcome Katarzyna Kaczmarek-Gut and Maciej Turek to the team - find out more about them.
This sums up the last couple of weeks.
If you would like to be featured in one of our CKEditor updates, or have an interesting tidbit that relates to CKEditor, leave a comment below or contact us.
See you again in a month!