Problem/Motivation

#3222797: Upgrade path from CKEditor 4's StylesCombo to CKEditor 5's Style added the @ckeditor5/ckeditor5-style plugin.

But its plugin definition had its drupal.elements restricted to just HTML5 elements:

    elements:
      - <$any-html5-element class>

(And it has corresponding validation logic in StyleSensibleElementConstraintValidator — see \Drupal\ckeditor5\Plugin\Validation\Constraint\StyleSensibleElementConstraint::$nonHtml5TagMessage.)

Why?

  1. Drupal's CKEditor 4 integration (StylesCombo) never supported setting styles on e.g. <drupal-media> — heck, not even on <img>!
  2. In the CKEditor 5 equivalent (Style), images and Drupal media are impossible to support today, because they're implemented as "widgets", and I quote: Widget styling is out of the picture for now. — source: issue 5700. This is fine because this didn't work in Drupal 8 either — see #2642808: [upstream] CKEditor Style for <img> not working because it is an "image" widget + #3117172: Allow CKEditor styles for <drupal-media>.
    For images this is arguably bad, but for Drupal media this is arguably fine: because those allow choosing a view mode already: #3074608: Optionally allow choosing a view mode for embedded media in EditorMediaDialog.
    Combine this with the fact that the Drupal ecosystem is moving from "plain images" to "image media" — especially post-migration from Drupal 7 thanks to migration modules like https://www.drupal.org/project/media_migration, the value of making this work for plain images (<img>) is diminishing.
  3. In the CKEditor 5 equivalent (Style), integration with GHS is incomplete, which means that some elements may not be able to use Style yet.
    Since CKEditor 5's official plugins only support official HTML5 elements, the obvious thing to do is to restrict the allowed HTML elements to configure Style for to just … HTML5 elements. Hence the validation logic mentioned above!

Steps to reproduce

N/A

Proposed resolution

Wait for Style to stabilize further, and in particular for it to gain full GHS support. Then we can consider allowing configuring styles for non-HTML5 tags.

Remaining tasks

TBD

User interface changes

TBD

API changes

TBD

Data model changes

TBD

Release notes snippet

TBD

CommentFileSizeAuthor
#6 cke4-styles.jpeg342.3 KBwill_frank
#6 cke4-style-dropdown.jpeg173.37 KBwill_frank
#6 cke4-source.jpeg114.27 KBwill_frank
#6 cke4-allowed-html.jpeg344.2 KBwill_frank

Comments

Wim Leers created an issue. See original summary.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Issue summary: View changes
wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Issue summary: View changes
will_frank’s picture

will_frank commented

I have a question. This issue is blocking us from adopting CKEditor 5
because we have a custom style that generates a non-HTML5 tag.

The question is given recent signs that this issue has been addressed
(see https://www.drupal.org/project/drupal/issues/3268306 point 20
where Wim Leers states
But today (thanks to #3301495: Update CKEditor 5 to 35.0.1), it gets converted to:

p

yo

So … the bug has indeed been fixed upstream!

So is a patch already available for this issue to try a fix? Or is a fix
coming soon. I would be happy to test if something is available.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented

I think you're misinterpreting #3268306-20: [GHS] Custom/unofficial HTML tags not retained: <drupal-media>, <drupal-entity>, <foobar>. Custom, non-HTML5 tags are retained now, but that doesn't mean that Style supports setting values on them. That's a wholly different matter, and it's very uncertain whether that will happen any time soon — if ever.

What tag are you using? Because AFAICT it never worked in CKEditor 4 either. If you can prove it worked in CKEditor 4, that'd change things.

will_frank’s picture

will_frank commented
StatusFileSize
new cke4-allowed-html.jpeg344.2 KB
new cke4-source.jpeg114.27 KB
new cke4-style-dropdown.jpeg173.37 KB
new cke4-styles.jpeg342.3 KB

To answer Wim Leers question:
"What tag are you using? Because AFAICT it never worked in CKEditor 4 either. If you can prove it worked in CKEditor 4, that'd change things."

Our site is currently Drupal 9.5.1, using CKEditor. We have used CKEditor since our launch a couple of years ago with Drupal 8.

Attempting now to upgrade to CKEditor 5, we are encountering that a custom html tag we have been using is now:
1) being stripped out from the content entered in CKEditor 5, and
2) the custom Style we've used to apply this tag is no longer allowed by CKEditor 5 and had to be removed before the text format could be saved.

The custom html tag is 'fnote'. We have had this tag is in the "Allowed HTML tags" filter of the text format.
The custom style for this (in the text format's Style drop-down) is:
fnote|Short footnote

As mentioned, this has worked fine for our site, using CKEditor, since our launch a couple of years ago now. The content of the tag is processed and transformed into footnotes during the page rendering (this 'fnote' tag is no longer present in the rendered, cached, content), having nothing to do with CKEditor anymore. The tag is entered by the user and saved, with the tag, to the database. Up until now CKEditor has allowed and saved this tag without complaint.

If we are not able maintain this functionality, the 'fnote' tag in our existing content will be removed the next time content is edited, and we would have to rewrite our footnote module and change thousands of pieces of content to correct it.

When we change the text format to use CKEditor 5, we find that the Style drop-down will now only accept standard html5 tags, and throws an error until the offending 'fnote' is removed from the Style list. We also find that other lines in the Style list are not allowed even though they are standard html. The message is that since these are in the Source editing list they can't be in the Style drop-down.

We could deal with that by manually editing, which we tried: In the new CKEditor 5, we added this 'fnote' tag to the new Source editing field of the text format (actually, the migration process from CKEditor->CKEditor5 added it there), and the tag is in the "Allowed HTML tags" field. BUT, when we edit content, select Source, and enter the 'fnote' tag, it is stripped out by CKEditor as soon as Source is clicked again.

Our main concern is that CKEditor 5 strips out the 'fnote' tag, which as mentioned would affect a great deal of our existing content. If we have to we'll have our users enter 'fnote' manually.

We see that CKEditor 5 itself (upstream) now seems to have no problem retaining a non-standard html tag. Is the problem related then to the Drupal module? Do we need to configure something? Are we doing something wrong?

As mentioned, this non-standard, custom, html tag ('fnote') has been allowed and accepted by CKEditor all this time until this upgrade.

Please see attached screenshots of existing functionality. (FYI, we have two choices with for our users: short and long. The long version is 'fnote class="fnotelong"'.)

will_frank’s picture

will_frank commented

We have done further investigation into the issue of CKEditor5 *not* retaining non-HTML5 tags
and filed a separate child issue. For details see:
https://www.drupal.org/project/drupal/issues/3335991

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Title: [upstream] Consider allowing styles for non-HTML5 tags » [PP-1] [upstream] Consider allowing styles for non-HTML5 tags
Related issues: +#3335991: [upstream] [GHS] CKEditor 5 does not retain custom HTML tags that are not defined by CKEditor 5 plugins whenever /.*/ is not allowed (e.g. when filter_html is enabled)

Definitely blocked on #3335991: [upstream] [GHS] CKEditor 5 does not retain custom HTML tags that are not defined by CKEditor 5 plugins whenever /.*/ is not allowed (e.g. when filter_html is enabled).

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented

#3347721: [Style] Warn the user about styles for unsupported elements just made this easier to discover 👍

Version: 10.0.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

bkosborne’s picture

bkosborne
Primary language English
Location New Jersey, USA
commented

See also this support issue I created in CKE5 issue queue which asks how to make custom widgets compatible with the Style plugin.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.