Upgrade path from CKEditor 4's StylesCombo to CKEditor 5's Style

Problem/Motivation

Drupal 8/9 ship with CKEditor 4's StylesCombo plugin/feature: https://ckeditor.com/docs/ckeditor4/latest/features/styles.html

This shipped with the original CKEditor 4 issue: #1890502: WYSIWYG: Add CKEditor module to core. It provides a configuration UI:

When talking to the CKEditor developers:

We didn’t work on a replacement yet. We’re not even sure whether it’s needed and what’d be the use cases.
There’s a very old ticket: https://github.com/ckeditor/ckeditor5/issues/648 where we started some discussion. There’s also https://github.com/ckeditor/ckeditor5/issues/5700. But in general it’s unclear for us what would this feature be for.

What use cases do you see for it?

My response:

Well … how do we provide an automatic upgrade path in Drupal? 🤔

StylesCombo in CKE4 can only be mapped to heading.Heading in CKE5 as long as it’s only touching <h*>— but StylesCombo allowed much more. How do we automatically take any arbitrary StylesCombo configuration and make it work in CKE5?

It’s fine if it maps to multiple plugins but we do need to provide an upgrade path.

To which they responded:

Yeah, from the upgrade path perspective, there’s certainly a clear reason to do something on our side. What was blocking us so far is that we don’t want to create again a feature that duplicates a big part of the headings dropdown functionality. Thus, product-wise, it’s tricky.

Proposed resolution

Wait for https://github.com/ckeditor/ckeditor5/pull/11349 to ship with the April 6 release of CKEditor 5.

It shipped: #19. 👍

Remaining tasks

• ✅ add @ckeditor/ckeditor5-style package
• ✅ basic functionality
• ✅ TEST: unit
• ✅ TEST: kernel: SmartDefaultSettingsTest expectations should be updated
• ✅ TEST: functional JS for plugin settings
• ✅ TEST: functional JS for using the plugin
• ✅ Upgrade path
• ✅ Additional validation constraints to ensure config always is valid
• ✅ TEST: kernel: new test cases in ValidatorsTest:
  Validator test coverage, which conveys just how precise validation is, which is extra important because as described in #46, the CKEditor 5 Style plugin itself does not do any validation:
  1. INVALID: Style plugin with no styles→ when no styles are configured, having the toolbar item enabled is pointless (this is the only one already passing because it's the only one already implemented)
  2. INVALID: Style plugin configured to add class to unsupported tag→ it does not make sense to allow adding a class to a tag that cannot actually be generated!
  3. INVALID: Style plugin configured to add class that is supported by a disabled plugin→ it does not make sense to allow adding specific classes through a Style that can be supported by enabling a disabled plugin (for example "Alignment")
  4. INVALID: Style plugin configured to add class that is supported by an enabled plugin→ it does not make sense to allow adding specific classes through a Style that are already supported by another plugin (for example "Alignment")
  5. INVALID: Style plugin has multiple styles with same label→ without unique labels, it'd have terrible usability and accessibility
  6. INVALID: Style plugin has styles with invalid elements→ not possible to configure this through the UI, but … it is possible if you modify the configuration directly.
  7. VALID: Style plugin has multiple styles with different labels→ the sole example of a sane configuration, and hence the only not resulting in a validation error

User interface changes

New plugin settings form.

API changes

None.

Data model changes

None.