Problem/Motivation
Thanks to #3228334: Refactor HTMLRestrictionsUtilities to a HtmlRestrictions value object, #3259174: Add missing CKE5 SmartDefaultSettings test coverage (wildcard tag with unsupported attribute) and #3259367: [upstream] Avoid allowing alignment on all <$block> tags, we discussed this challenge with the CKEditor 5 team in the January 20, 2022 meeting. That is how we found out that <$block> in CKEditor 5 largely maps to HTML 5 block-level elements, but not exactly.
This means that the automatic upgrade path we are providing from CKEditor 4 to CKEditor 5 is not guaranteed to support all attributes on block-level elements through CKEditor 5 plugins it enabled, on text formats with HTML restrictions that list allowed tags/attributes/attribute values (essentially: those using filter_html).
Crucial: all tags are still guaranteed to be supported (<$block> does not add support for explicit tags, but adds support for attributes and/or attribute values on already supported tags). The only thing that we need to add explicit support for, are attributes/attribute values on tags that Drupal thinks <$block> implies, but are not actually supported. We can add support for them on the fly using the GHS plugin.
This is technically a data loss problem, because it is possible that pre-existing content contains an attribute on a tag that Drupal thinks a CKEditor 5 plugin has support for, but this is not actually true. Therefore marking this critical
, even though the actual real-world impact is likely very minimal.
We know of no real-world cases (yet) where data loss would occur. This is theoretical, but important nonetheless.
Proposed resolution
Configure GHS with a configuration where wildcards have been resolved based on Drupal's assumption on what the wildcard should be resolved into. This can be all done on Drupals side since we know which tags and attributes should be supported. For the elements that are directly supported by a plugin, GHS acts only as a fallback, and the plugin that provides support for the tag will be still responsible for converting it.
Example: <h2> is supported by the heading plugin which would be responsible of adding <h2> as a supported tag. The source editor could have additional configuration of <$block class>. This could be resolved into <h2 class>. In this case, since the heading plugin is enabled, the <h2> element would be converted by the heading plugin. When there is a class attribute on the <h2> element, the element would be still converted by the heading plugin, but the class attribute would be converted by GHS, unless the heading plugin (or some other plugin) explicitly provided support for the class attribute.
Remaining tasks
TBD
User interface changes
TBD
API changes
TBD
Data model changes
TBD
Release notes snippet
TBD