Problem/Motivation
Currently, the Klaro consent window/content blocker lacks Drupal-specific HTML and CSS, as it uses the default styles provided by the upstream library. Consequently, the checkboxes, colors, and other elements do not align with the styling of the surrounding Drupal theme.
For example, themes like Olivero, Claro, and Gin have distinct ways of styling checkboxes and other UI components, which are not reflected in the Klaro-related elements.
This raises the question of whether we should implement theme-specific styling to ensure that the content blocker window matches the look and feel of the surrounding theme. For instance:
- In the Gin backend theme, the content blocker should look native to Gin.
- Similarly, when used in the Olivero theme, the content blocker should reflect the frontend theme’s styling.
Proposed resolution
Introduce a “custom CSS file” for each Drupal theme and load it "dynamically" based on the active theme.
This could be achieved by querying the currently active theme and loading the corresponding Klaro styles specific to that theme.
Remaining tasks
- Initiate a discussion to determine if this approach is necessary.
- Consider the effort required versus the benefits gained.
- In my opinion, this may involve significant effort.
- A better solution might be to address the issue upstream by aligning the Klaro markup with Drupal’s default markup standards. This would reduce the need for theme-specific adjustments.
| Comment | File | Size | Author |
|---|---|---|---|
| #25 | claro-whcm.mp4 | 449.09 KB | rkoller |
| #24 | olivero-whcm-toggle.mp4 | 144.94 KB | rkoller |
| #24 | olivero-whcm.mp4 | 87.52 KB | rkoller |
| #17 | border.jpg | 154.16 KB | rkoller |
| #17 | claro.mp4 | 1.05 MB | rkoller |
Issue fork klaro-3495342
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #4
jan kellermann commentedWe have no frontender at hand in the moment.
I opened a MR which will add class
klaro-theme-<theme_name>to every klaro-element.Here is the Klaro-SCSS with all defined vars you can easyly override:
https://github.com/klaro-org/klaro-js/blob/master/src/scss/vars.scss
And I uploaded our SCSS-file which we use for customizing (renamed to TXT).
Comment #5
jurgenhaasI don't think Klaro should be responsible to style for any number of themes. At most, it should provide an infrastructure so that themes can make the Klaro visuals look nice. Therefore, extra classes like in the MR should not be necessary, the currently active theme would style the available components and there shouldn't be any CSS that needs the context of different themes.
The only exception should be Claro, Gin and Olivero as they are Drupal Core or Drupal CMS defaults.
For those themes, I wonder if the Klaro CSS could just leverage the CSS variables to define the Klaro styling. I would assume, that those 3 themes use the same, or very similar variable names and hierarchies.
Comment #6
jan kellermann commentedThey are using similar classes - but klaro not.
The variables are quite different - because of this I would just add the theme as class and then write custom css for these three theme which uses the variables and adjust the klaro-classes with their theme equivalents.
Comment #7
anybodyGuess this might be another reason for a potential Drupal fork of Klaro lib one day perhaps, so the classes and elements could use Drupal standards.
That should just happen, if the original maintainers from Klaro don't maintain the lib anymore or the Drupal maintainers are much more active maybe? (Perhaps we should open a meta issue for the far future to track such benefits?
(Disclaimer: I have no idea how good the cooperation and communication with Klaro team is. Of course, it would be best to share the boat with them!)
Comment #8
kgertzShouldn't the respective theme be responsible for the actual styling? No matter what produces the markup (be it a drupal module, field formatter or a react app) - the theme would be the common place to specify a certain look & feel for it (?) I don't even see the necessity that the klaro markup should be more "drupalish"...
As for Olivero, there is a subtheme used anyway (drupal_cms_olivero) in Drupal CMS which could easily be extended by a custom stylesheet for klaro.
Regarding Gin I'm not so sure whether it is easily possible to create a subtheme. On the other hand, Gin has this nice mechanism to provide custom styles in a file public://gin-custom.css - would it be possible to add klaro-specific styles to Gin that way? Can e.g. a recipe modify files in the public file system?
Anyway, I don't see this as a klaro issue.
Comment #9
jan kellermann commentedI added an option for overriding the Klaro! CSS (keeping backward compatibility for existing installs).
The CSS standardizes the buttons and display and introduces CSS variables that can be easily overwritten in your own theme (see here).
There are also customizations for the Olivero, Claro and Gin themes.
Please review and feedback.
EDIT: If you are updating your existing Klaro!, you have manually enable the option. "Override Klaro! CSS" in tab "Styling". For legacy reasons we do not enable while updating - only fresh installs get this option enabled per default
Comment #10
rkollerThank you for the MR! Initially i've struggled quite a bit cuz i've only faced the klaro upstream styling until i've realized i have to check the "override klaro css" option. :/ in general i like the direction the MR is going. but there are a few details to note about the styling:
all themes:
privacy policyand thepowered by klarolink, the checkbox labels and the toggle buttons to expand and collapse the services groups.Claro:
Olivero:
Gin
admin/appearance/settings/ginor on the user profile if overrides on a per user basis are active.Comment #11
jan kellermann commented@rkoller thank you for your quick and incredibly comprehensive and helpful feedback!
I've added a note about the update process and how to manually enable the option. (Sorry for wasting your time).
I tried to solve the first and second issue:
Edit: not sure of the white shadow should be set for focus and / or for focus-visible, see here.
The checkboxes / toggle buttons are part of Klaro! and we cannot change. So we shoul fix further styling and ally issues.
The other issues I will have a look later.
Comment #12
anybodyThank you very much once again @jan kellermann for the great work here.
I just have a comment regarding wording: I'm not sure if
is perfectly matching what it does. The site owner may not know that Klaro! has its own CSS anyway, and what overriding means here. I think reading
I'd expect a functionality that let's me override the CSS (not knowing if it comes from the Klaro! Lib or the module), maybe in the UI or in a theme, but that's not the case (and not our goal).
Perhaps something like: "Use Drupal-like styles" is clearer and should then be enabled by default for new installations?
But there might be even better terms. The description should then explain details.
Of course, we can improve the wording later, if we have better ideas, this is not a blocker.
Comment #13
jurgenhaasThank you @jan kellermann this is certainly going the right direction. Great progress.
Comment #14
jan kellermann commented@all Thank you for feedback. Lets rock the last meters to the 1st stable release!
@rkoller:
@anybody: I just changed the wording. And, yes, the option is automatically set for new installations. But not when updating for compatibility reasons.
Please further feedback or RTBC.
Comment #15
rkollerThanks for the changes. A few more observations and thoughts:
micro copy:
i completely agree with @anybody that the previous label
Override Klaro! CSSwas unclear and confusing, butUse Drupal-like stylesi not necessarily consider explicit and clear as well. As a user it makes me think what drupal like refers to? But the wordsmithing might lead into bikeshedding but i guess as long as the styling and a11y issues arent ironed out we could still keep discussing the wording for now;) and in regard what to write instead, i would label what this checkbox is all about, using or adjusting the styling of klaro to the installed drupal themes. and in the description i would add that klaro provides out of the box the styling for the two core themes olivero and claro as well as gin. and maybe also provide a link to a docs page how to handle the case if another frontend theme instead of olivero is being set as the default theme? so a site builder is being able to provide bespoke css for their theme of choice?Update: and i forgot to add, would it make sense to make the checkbox per default checked for klaro? if not i would suggest to at least update the recipe for drupal cms and tick the checkbox there per default at least?
All themes:
Gin (light mode):
the notice and the consent dialog are both minding now the selected accent and focus color - fab! one thing that is confusing, the toggle buttons stick to the strong green background color. but if you change to the dark mode that background color for a toggle is following the set accent color as well now? is that intentional for gin or is that sort of a bug (i am using 4.0.0) - it is definitely an inconsistent behavior in between light and dark mode for gin?
The customize link on the notice, the privacy policy, the services group toggle, the toggle buttons and the powered by link on the consent dialoge still have the blue focus outline instead of the current selected focus color.
Gin (dark mode):


the background color is still white there. and there is sort of a white margin even outside the focus outline.
and circling back to the gin light mode the notice modal is hard to recognize against a white background without the focus outline active.
The customize link on the notice, the privacy policy, the services group toggle, the toggle buttons and the powered by link on the consent dialoge still have the blue focus outline instead of the current selected focus color.
Olivero:
the focus outline around the notice modal is visible... but the color for the focus outline for the notice modal and the focus outlines within the modal differ that is for sure, plus the real problem the focus outline is invisible for the blue primary buttons. (and the pattern that is listed for gin and claro applies here as well -> The customize link on the notice, the privacy policy, the services group toggle, the toggle buttons and the powered by link on the consent dialog modal still have the blue focus outline instead of the olivero outline
Claro:
The customize link on the notice, the privacy policy, the services group toggle, the toggle buttons and the powered by link on the consent dialog modal still have the blue focus outline instead of the green.
Update: yuck, completely forgot about the windows high contrast mode. need to check all the different themes and settings as well. will take some more time.
Comment #16
grienauerWhen I discussed this issue at a 1:1 meeting with Ralf, and then wrote together this idea, I was not sure if this is the right way.
My first suggestion would have been fixing it upstream and then, that the theme itself provides some stylings.
But the aim was, having a working solution asap and I am baffled, how quickly here a solution was developed.
I think after drupal cms v1 we should overthink this solution (maybe just move the custom css into the belonging themes, but it feels really great, that there will be a solution for now!
When we met IRL, the first juice/beer/cocktail is on me :)
Comment #17
rkollerwent through the three themes in high contrast mode:
all themes:

for the notice a drop shadow is not available in high contrast mode, so in every of the following videos you will notice an outline is completely missing, only claro has at least a focus outline, but a border is missing entirely (same for the consent dialog modal). i would suggest to go with the approach used on the dialog modals in drupal core and simply use a border same as for the dialog modal on for example a view.
Olivero (olivero.mp4) & Gin (gin.mp4):
notice dialog
consent dialog
declineandaccept selectedhas no visible focus outlineClaro (claro.mp4):
notice dialog
consent dialog
Comment #18
jan kellermann commentedThank you for large and exact feedback! I hope I solved all bugs you described.
micro copy:
Title: Adapt the UI to Drupal
Desc: Activate this to overwrite the Klaro! styling with a Drupal-like appearance. There are also customized designs for Olivero, Claro and Gin.
Documentation:
https://git.drupalcode.org/issue/klaro-3495342/-/blob/3495342-stylings-p...
Later we will add a documentation page for styling.
The option is automatically set for new installations, but not when updating for compatibility reasons.
Changes
target sizes (all themes):
- Fixed close-button to 24x24px
gin (light):
> the toggle buttons stick to the strong green background color. but if you change to the dark mode that background color for a toggle is following the set accent color as well now
solved.
> links on the consent dialoge still have the blue focus outline instead of the current selected focus color.
solved.
gin (dark):
> the background color is still white there. and there is sort of a white margin even outside the focus outline
solved.
> and circling back to the gin light mode the notice modal is hard to recognize against a white background without the focus outline active.
solved.
> links on the consent dialoge still have the blue focus outline instead of the current selected focus color.
solved.
Olivero:
> focus outline for the notice modal and the focus outlines within the modal differ
done.
> focus outline is invisible for the blue primary buttons
done.
> links still have the blue focus outline instead of the olivero outline
fixed (is same as link color - currentColor).
Claro:
> The customize link on the notice, the privacy policy, the services group toggle, the toggle buttons and the powered by link on the consent dialog modal still have the blue focus outline instead of the green.
fixed.
windows high contrast mode:
Tried my best. Maybe an own ticket because larger scope than this.
Comment #19
rkollerThank you for all the work! A few comments:
I am part of the group of people working on Drupalisms in Drupal, we are still mainly in the audit phase collecting the set of nouns, verbs and adjectives that build the mental model and grammar for drupal, there happened no discussion nor work uni- and clarifying the wording yet. but there is at least one detail i try to recommend and mind myself: i would first look at the current list for any noun, verb and adjective in question.
Adaptis a verb that not looked like the perfect pick and also looked unfamiliar to me. taking a look at the current list at https://docs.google.com/spreadsheets/d/1p6i00ya_H9UHVagbpAUrJuuyw7GlUU4e... it turned out thatAdaptwasn't listed yet. Did a quick global search in a core installation in vcode andAdaptwas only found once in a help topic and aside that three or four more times in code comments. Personally I thinkAdjustwould be more precise? Plus adapt "to Drupal" is also sort of imprecise, it might be sort of misleading in case a site administrator has installed a custom default theme that is not olivero and or neither claro/gin then the actual purpose of that checkbox might be potentially confusing same as the actual outcomes? How about:Adjust the Klaro UI to the default and administration themeIt would use the verb adjust which is already used across the admin ui and which is more suitable in this context, making it more explicit which UI is adjusted and finally clarify to what the klaro ui is adjusted to, which is the chosen default and administration theme. it is a bit more verbose but clearer and more explicit from my point of view.
the phrase "Activating this...." or "Activate this" is sort of redundant and unnecessary. A user has to skim by that snippet until the details of interest start. In the micro copy for descriptions in core in general that stylistic device isnt used. How about something like:
Klaro provides styles for Olivero, Claro, and Gin. Learn more [how to adjust Klaro to your own themes].It is front-loaded that klaro provides styles for olivero, claro, and gin, which is the "default" when this option is active, and then you provide a direct link to the docs page you've mentioned for the case a user is using their own theme. definitely not perfect yet but just an initial idea how to rephrase and shorten that description?
Styling:
Olivero
notice:
notice: (windows high contrast)
consent
consent (windows high contrast mode)
Claro:
notice:
consent: (windows high contrast)
gin (light)
notice:
notice: (windows high contrast)
consent
consent (windows high contrast mode)
gin (dark)
notice:
notice: (high contrast mode)
consent
consent (windows high contrast mode)
i hope i got everything now. jumping inbetween browsers, themes, different states, and settings is super confusing. i think if the points i've listed are solved, the current state of the MR would be a significant improvement. some more work might be still required about the styling of the notice dialog, in particular the styling of the toggle button component, as well as you've already mentioned, the styling in the context of the windows high contrast mode, but i would move those to follow-ups probably?
Comment #20
rkollerComment #21
jan kellermann commentedTitle and description:
The new CSS contains basic Drupal rules and colors. There are also customizations for the three themes. However, the main goal is to replace the Klaro! look with the Drupal style. Therefore I have customized it:
Title:
Adjust the UI to Drupal styleDesc:
Use Drupal-like appearance for Klaro! elements. There are also customized designs for <em>Olivero</em>, <em>Claro</em> and <em>Gin</em>.Styling:
Olivero
notice:
Reduced size.
Yes, because links have "currentColor" and buttons another color.
notice: (windows high contrast)
Fixed.
consent
The focus has "currentColor" as color and this should be identical to link.
Fixed.
consent (windows high contrast mode)
Because klaro-js set focus and key-down sets focus-visible. Focus has no browser preset but focus-visible. Dont fix.
Fixed.
Claro:
notice:
Like at all others variants. Its basic style from klaro. wont fix.
consent: (windows high contrast)
Its autofocused, cant reproduce.
Its autofocused, cant reproduce.
gin (light)
notice:
Yes, it is correct (dont know why Gin does this).
Gin uses shadow instead of outline. Wont fix.
notice: (windows high contrast)
Links in Gin have no focus outline in high contrast mode. Wont fix.
consent
There is no outline offset for Gin theme, shadow as expected in Gin theme. Dont fix.
consent (windows high contrast mode)
Toggles have a focus outline. All links are missing an outline according to Gin theme. Wont fix.
gin (dark)
notice:
This is the default focus from Gin. wont fix.
notice: (high contrast mode)
Links in Gin have no focus outline in high contrast mode. Wont fix.
consent
It is the same double-shadow with 1 px darker inner shadow as Gin specifies.
Cannot reproduce. The link has the same color (yellow) as all other links (
Fixed.
consent (windows high contrast mode)
See above.
Thank you very much for the extensive feedback once again! But I have to finish this issue. If there are no more significant problems, I would like to merge.
Comment #23
jan kellermann commentedComment #24
rkollerApologies for the delay. I went into the rabbit hole of reevaluating the gin audit which is also relevant for klaro in consequence (and i am far from finished yet but remembered the klaro issue in todays track meeting when the discussion got to open and remaining tasks.. i'll step through the list of changes and only comment if necessary or if i notice something new to keep the comment shorter:
title and description
i liked you changes in #21
( i would even consider to strike the word "also" as it is sort of a filler)
but in the interface i currently see:
Gin
notice:
the only problem i see taking a closer look, something i've missed so far. the outline for the dialog and the two buttons has with rgb(82, 179, 234) against rgb(250,250,250) only a color contrast of 2.2:1 but 3:1 would be required (plus the buttons have also the problem of simultaneous contrast close to the focus outline - got eased by the introduced offset)... but the color contrast is rather something for a follow up or an issue in the olivero issue queue.
notice: (windows high contrast)
i am unable to confirm that in edge on macos (see olivero-whcm.mp4)
consent(windows high contrast mode)
i am unable to confirm that either unfortunately (see olivero-whcm-toggle.mp4)
Claro
consent(windows high contrast mode)
see claro-whcm.mp4
Gin
Going through your comments and with the fresh memory of the current reevaluation of the gin audit it is definitely the right call to make the fixes upstream in gin first. so i spare you with more nitpicks for gin ;)
so overall the current changes are a huge improvement over the previous state, a tremendous effort on your end. thank you for that! probably best have a quick chat about the remaining points from my comment on slack after you've reviewed them maybe? but commit the issue right after and then focus on fixing issues upstream in olivero, claro, gin and klaro.js and then do the final cleanup in a followup in klaro. what do you think about that plan?
Comment #25
rkolleri've missed uploading the referenced claro video, apologies
Comment #26
jan kellermann commentedMany thanks for the comprehensive and accurate feedback again. It is a great pleasure to work with you!
title and description
Changed in code and README now. ("also" is correct because there is a standard-style with drupal colors and additional three styles for the known themes).
Olivero
notice: (windows high contrast)
Fixed.
consent (windows high contrast mode)
On windows they have a 2px dotted white outline (I removed now the transition of 0,4 seconds).
Claro:
consent (windows high contrast mode)
On windows the outline is visible.
Gin:
windows high contrast mode
I force now the outline for links.
Also done:
Thanks for the suggestion to chat directly and clarify what needs to be done before the merge.
Comment #27
jan kellermann commentedSet to RTBC after final discussing on slack.
Just resolving last stylelint issues and then merge.
Thank you all for feedback and testing. We couldn't have done it without your support!
Comment #28
jan kellermann commentedMerged and fixed.
Comment #31
rkoller