Problem/Motivation

Claro and Olivero are adding front-end styles inside the CKEditor 4 iframe. With CKEditor 5, those styles need to be written so that they are specifically catering CKEditor 5, since CKEditor 5 is not loaded in an iframe. Decide how much of this CSS should be rewritten for CKEditor 5.

Until this is fixed, we'll see this in the Text Formats & Editors UI:

Proposed resolution

Since CKEditor 5 already ships with modern design out-of-the box, the proposed solution is to not rewrite any of the CKEditor 4 CSS for CKEditor 5 in any of the themes (at least for now).

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

lauriii created an issue. See original summary.

mherchel’s picture

Speaking as a theme maintainer and a person who works creating and maintaining themes for companies, I don't think it's a big deal to do a minor re-write of the styles assuming that we're just adjusting parent selectors or specificity.

99,9% of people going from Drupal 9>10 will be making at least some code changes, and changing around parent selectors isn't a big deal (even for backend devs), if they know they. need to do it.

That all being said, if we can get away with not having to do this one extra task, then that's that much easier and one less thing to worry about.

lauriii’s picture

The API was already added in #3194084: Support functionality equivalent to ckeditor_stylesheets. This issue is about deciding what to do about Olivero, Bartik, and Claro; should we rely on CKEditor 5 default styles or override those in the specific themes?

Something that is worth noting is that CKEditor 5 ships with much better default styles. For that reason I think at least Claro should remove it's CKEditor 5 styles and just rely on the default styles.

mherchel’s picture

I mis-read that then. In that case, it probably makes sense to at least provide the basic typography rules (font, headings, etc).

Wim Leers’s picture

it probably makes sense to at least provide the basic typography rules (font, headings, etc).

To clarify: do you mean Olivero's typography?

Wim Leers’s picture

Title: Decide what to do about theme specific CKEditor 5 CSS files » Decide what to do about theme-specific CKEditor 5 CSS files
mherchel’s picture

To clarify: do you mean Olivero's typography?

yeah 🤷‍♂️😆

I've spent a bit of time this morning thinking about how to bring in the styles without affecting the rest of the page. Looking through PostCSS Preset ENV tooling, I don't see anything that can do it. From what I understand the @apply rule is not on track for inclusion in native CSS and thus isn't in PostCSS Preset ENV.

We might need to have duplicate code, which kind of stinks. But at least we can then be very granular about what we want to include.

Wim Leers’s picture

Assigned: Unassigned » lauriii

@mherchel AFAICT what @lauriii is proposing is to not make the markup edited & previewed through CKEditor 5 match the default front end theme, but just to give it sensible default typography.

Assigning to @lauriii for feedback.

lauriii’s picture

AFAICT what @lauriii is proposing is to not make the markup edited & previewed through CKEditor 5 match the default front end theme, but just to give it sensible default typography.

My main argument for this is that not styling the text editor like the frontend would create a more consistent experience. Drupal is focused on structured data and we are not making structured data render like the frontend either, so why would we try to do that for the text editor since after all the rendering of the text editor and the frontend are totally separate.

I think we should also make it clear that there is separation between the theme and the content. The theme could be rebuilt but the content would still remain still the same. I think that the CKEditor built-in styles do a good job at describing those semantics.

So why are we allowing loading stylesheets in the first place if that's not what we recommend for the core themes?

There are cases where it makes sense for the theme to be able to enhance styles. A good example of this would be styles required by stylescombo. In my opinion, it would not be reasonable to assume that all stylescombo related CSS would have to come from a module. This does create some coupling between the theme and the content but I guess there's always some of that to the certain extent since in the end, themes are responsible for representing the content.

We might need to have duplicate code, which kind of stinks. But at least we can then be very granular about what we want to include.

That's what we sort of assumed in #3194084: Support functionality equivalent to ckeditor_stylesheets. There isn't good solution for the CKEditor 5 side due to limitations in the selection web APIs that are still lacking support for shadow roots.

lauriii’s picture

Assigned: lauriii » Unassigned
Issue tags: +Needs subsystem maintainer review

Didn't mean to remove the subsystem maintainer tag yet.

mherchel’s picture

I talked this over with @lauriii earlier today. I agree that it's not necessary to have the front-end styles within the admin WYSIWYG as long as the WYSIWYG styles visually convey the semantics of the text, which is the case with CK5.

Furthermore in many cases, it's actually desired since the WYSIWYG is smaller than the viewport and large text can look out of place.

bnjmnm’s picture

I'm +1 on using the default CKEditor 5 styling vs bringing in default theme styles, but is the media-embed-error css something that should be provided in ckeditor5-stylesheets: since it's styling a UI component vs the actual editor content?

Wim Leers’s picture

Issue summary: View changes
FileSize
26.64 KB

Thanks to #3304256: Remove Bartik from Drupal core, I don't think Bartik is a concern anymore.

That still leaves Claro & Olivero. Because we currently see this in the Text Formats & Editors UI:

lauriii’s picture

Assigned: Unassigned » lauriii
lauriii’s picture

It seems like ckeditor5-stylesheets: false which has been documented on https://www.drupal.org/node/3259165 does not work. In true self-service fashion I fixed that so I can use it in Claro and Olivero. Also added test coverage to ensure this actually works.

lauriii’s picture

Title: Decide what to do about theme-specific CKEditor 5 CSS files » Add ckeditor5-stylesheets: false to Claro and Olivero (and fix it 😅)

The last submitted patch, 15: 3285054-15-test-only.patch, failed testing. View results

Wim Leers’s picture

Status: Needs review » Reviewed & tested by the community
+++ b/core/themes/claro/claro.info.yml
@@ -166,6 +166,8 @@ ckeditor_stylesheets:
+ckeditor5-stylesheets: false

+++ b/core/themes/olivero/olivero.info.yml
@@ -88,3 +88,5 @@ ckeditor_stylesheets:
+ckeditor5-stylesheets: false

These will be removed in #3270438: Remove CKEditor 4 from core, because there ckeditor_stylesheets will be removed as well!

So … 🚢!

  • bnjmnm committed e4d7b69 on 10.1.x
    Issue #3285054 by lauriii, Wim Leers: Add ckeditor5-stylesheets: false...

  • bnjmnm committed 39aa620 on 10.0.x
    Issue #3285054 by lauriii, Wim Leers: Add ckeditor5-stylesheets: false...

  • bnjmnm committed a385888 on 9.5.x
    Issue #3285054 by lauriii, Wim Leers: Add ckeditor5-stylesheets: false...
bnjmnm’s picture

Status: Reviewed & tested by the community » Fixed

Been hoping to see those messages go away for a while now, glad you spotted an issue & fixed it in the process. The test only patch makes it pretty clear that this is a good addition.

Merged to 10.1.x and cherry picked to 10.0.x and 9.5.x

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

Wim Leers’s picture

Version: 10.0.x-dev » 9.4.x-dev
Assigned: Unassigned » Wim Leers
Status: Closed (fixed) » Patch (to be ported)

The fix should still be backported to 9.4.x.

Will provide a patch. Currently not cleanly cherry-pickable. So determining what the optimal cherry-pick order is …

Wim Leers’s picture

Assigned: Wim Leers » Unassigned
Status: Patch (to be ported) » Reviewed & tested by the community

The #15 patch applies cleanly to 9.4.x — test running…

Wim Leers’s picture

Assigned: Unassigned » Wim Leers
Status: Reviewed & tested by the community » Needs work

Hm, that failed unexpectedly 😢

Wim Leers’s picture

Assigned: Wim Leers » Unassigned
Status: Needs work » Reviewed & tested by the community
FileSize
408 bytes
3.11 KB

The reason the #15 patch fails is that 9.5.x switched to Claro as the admin theme, and that was being used in the tests.

So all we have to do, is apply the pattern being applied here to Seven too in 9.4.x: indicate that there are no CKEditor 5 stylesheets for the Seven admin theme.

  • lauriii committed fd30ec0 on 9.4.x
    Issue #3285054 by lauriii, Wim Leers: Add ckeditor5-stylesheets: false...
lauriii’s picture

Status: Reviewed & tested by the community » Fixed

Committed fd30ec0 and pushed to 9.4.x. Thanks!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

bapi_22’s picture

We need a clean patch for Drupal 9.5 version.