Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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
Comment | File | Size | Author |
---|---|---|---|
#27 | 3285054-27-9.4.x.patch | 3.11 KB | Wim Leers |
#27 | interdiff.txt | 408 bytes | Wim Leers |
#15 | 3285054-15.patch | 2.78 KB | lauriii |
#15 | 3285054-15-test-only.patch | 1.25 KB | lauriii |
#13 | Screenshot 2022-08-31 at 12.48.21.png | 26.64 KB | Wim Leers |
Comments
Comment #2
mherchelSpeaking 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.
Comment #3
lauriiiThe 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.
Comment #4
mherchelI mis-read that then. In that case, it probably makes sense to at least provide the basic typography rules (font, headings, etc).
Comment #5
Wim LeersTo clarify: do you mean Olivero's typography?
Comment #6
Wim LeersComment #7
mherchelyeah 🤷♂️😆
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.
Comment #8
Wim Leers@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.
Comment #9
lauriiiMy 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.
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.
Comment #10
lauriiiDidn't mean to remove the subsystem maintainer tag yet.
Comment #11
mherchelI 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.
Comment #12
bnjmnmI'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?Comment #13
Wim LeersThanks 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:
Comment #14
lauriiiComment #15
lauriiiIt 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.Comment #16
lauriiiComment #18
Wim LeersThese will be removed in #3270438: Remove CKEditor 4 from core, because there
ckeditor_stylesheets
will be removed as well!So … 🚢!
Comment #22
bnjmnmBeen 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
Comment #24
Wim LeersThe 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 …
Comment #25
Wim LeersThe #15 patch applies cleanly to
9.4.x
— test running…Comment #26
Wim LeersHm, that failed unexpectedly 😢
Comment #27
Wim LeersThe 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.Comment #29
lauriiiCommitted fd30ec0 and pushed to 9.4.x. Thanks!
Comment #31
bapi_22 CreditAttribution: bapi_22 as a volunteer and for Globant commentedWe need a clean patch for Drupal 9.5 version.