Updating issue description
Gin Admin theme also does this to mitigate #32:
.ck-toolbar_grouping:focus,
.ck-toolbar__items:focus {
box-shadow: none;
}
}
This completely hides the green line around the toolbar. Not doing it in case it can have issues for accessibility. I think it's probably OK though: I'm not sure the toolbar should be focusable at all (the toolbar can still be used by the keyboard when the editor is focused), but in that case, we may consider focusing the editor automatically when the empty space in the toolbar is clicked.
Setting it to Ready for review, as I've created an MR that could be acceptable.
Replicating the hover effect could be a separate issue.
I found something simpler, looking at what Gin theme is doing:
--- a/core/themes/claro/css/components/ckeditor5.pcss.css
+++ b/core/themes/claro/css/components/ckeditor5.pcss.css
@@ -1,3 +1,6 @@
.ck {
--ck-color-base-border: var(--input-border-color);
+ --ck-focus-ring: 1px solid var(--color-focus);
+ --ck-focus-outer-shadow: 0 0 0 2px var(--color-white), 0 0 0 5px var(--color-focus);
+ --ck-inner-shadow: var(--ck-focus-outer-shadow);
}
This has the problems mentioned above, and a few pixels of the toolbar buttons are now below (behind) the green shadow, but I can't see how we could improve this if we apply current Claro's shadow:
I took a look and I don't think this is easy, it requires multiple style changes to CKEditor.
So this is totally doable. At least for a specific theme. For Claro, we'd want
--ck-color-focus-border: var(--color-focus);
This changes the color of the border from blue to green, but it is not much better, because as far as I can see, Claro implements the green outline with box-shadow.
Overriding the following selector gave me a better result:
.ck.ck-editor__editable.ck-focused:not(.ck-editor__nested-editable) {
box-shadow: var(--focus-box-shadow);
}
But still far from perfect: the CKEditor blue focus border is still there (and did not look good if removed, it should probably be converted to be var(--input-border-size) solid var(--input-border-color);
, but even then, the green outline still would not match Claro's, mostly because the focused element only has 2 rounded corners instead of 4 (which is another non-focus style difference):
Also, we would need to replicate the hover effect (border-color: var(--input--hover-border-color); box-shadow: inset 0 0 0 var(--input-border-size)...
).
And the issue I described in #32 would still happen.
That makes sense.
I see there is no CKEditor-dedicated file in Claro theme. I'm wondering if the right file to put this should be css/theme/field-ui.admin.pcss.css
, or maybe a new file css/theme/ckeditor.admin.pcss.css
should be created instead?
It didn't happen automatically, for some reason. And I don't see how this can be done manually.
Adding before/after screenshot changes. The field names are different in the screenshot, but the color issue applies.
@smustgrave, MR created, sorry: https://git.drupalcode.org/project/drupal/-/merge_requests/9728
@smustgrave hopefully should be OK now, MR is https://git.drupalcode.org/project/drupal/-/merge_requests/9729
pere orga → changed the visibility of the branch 3478281-ckeditor-5-has to active.
pere orga → changed the visibility of the branch 3478281-opcache-typos to hidden.
pere orga → changed the visibility of the branch 11.x to hidden.
Problem/Motivation
The term OPcache
should consistently follow its correct capitalization throughout the codebase and documentation. Variations such as "opcache" and "OPCache" are being used, which is inconsistent and can lead to confusion (and may look unprofessional)
Expected behavior
The term should always be written as "OPcache" to maintain proper case usage.
This will improve clarity and ensure consistency in the project's naming conventions.
pere orga → changed the visibility of the branch 3478281-ckeditor-5-has to hidden.
Pushed these changes:
/* Make border color consistent. */
.ck {
--ck-color-base-border: var(--input-border-color);
}
Issue created: https://www.drupal.org/project/drupal/issues/3478281 🐛 CKEditor 5 has its own border color and is not using Claro's colors Active
Hopefully addressed in https://git.drupalcode.org/issue/drupal-3478281/-/compare/11.x...3478281....
pere orga → changed the visibility of the branch 3478281-ckeditor-5-has to active.
pere orga → changed the visibility of the branch 11.x to hidden.
pere orga → changed the visibility of the branch 3478281-ckeditor-5-has to hidden.
pere orga → created an issue.
Applied and pushed.
pere orga → changed the visibility of the branch 3478132-fix-case-in to hidden.
pere orga → created an issue.
I think the standard nowadays (APCu >= 4.0.3) would be to check the following:
extension_loaded('apcu') && apcu_enabled()
Happy to create a separate issue, but there may be many other CSS inconsistencies, especially if this hasn't been a goal.
Regarding WCAG 2.2, shouldn't we aim to fix this upstream? Not only to avoid adding (and maintaining) more integration code that can break, but also to benefit the CKEditor project, and all the projects that use them.
Related to the focus, I also noticed that when clicking on any blank space inside the toolbar, the green outline appears around the toolbar, partially behind the preview/editor pane:
(not sure if this effect has been reported/identified before)
This issue is about focus styles, but shouldn't be about styles, in general?
What I first noticed is that the border is brighter in WYSIWYG fields:
(also, it is not resizable, but that would likely be a separate issue)
I agree this is not critical, nor very important. It would be great if consistency could be achieved, though. What I'm not sure is what would be the right solution, considering the toolbar also has a border.
Idea A:
Idea B:
Idea C:
@AstonVictor In Drupal 7, we have a feature that allows content managers to change the background color by using a color field. That way, the color is stored in the entity, and can be changed per entity.
In Drupal 10, it would be great to have support for Color Field and Color API module fields to restore this functionality.
Looks good, thanks!
Looks good to me, thanks
Done. Thank you!
This seems a valid feature request. I'm updating the title, as this is not only about accessibility.
Sorry, should be fixed now. Thank you for your message!
I thought I had properly attributed credit in the commit message, and I was not aware that these checkboxes did anything.
Thanks!
Thanks everybody. Dev and beta releases have been created. Let's continue the discussion at https://www.drupal.org/project/field_group_background_image/issues/3297197 📌 Automated Drupal 10 compatibility fixes Fixed
4.0.0-beta1 created too, which is now visible in the project page.
Thanks @nickrhymes! I just created https://www.drupal.org/project/field_group_background_image/releases/4.x... →
I personally don't have time at this moment, so this is currently not planned. But PR (and eventually, reviews of PR) are welcome.