How to change Patternfly default colours

[gabrielefronze]

Hello good people!

Thank you for the great tool cockpit is, I really am in love with it and I'm spreading the word with colleagues and friends.

I am on the way to customise it in order to (graphically) integrate it with an ecosystem I am working on and I would like to get some tips on how to override the default UI colours (mainly the blue/dark blue ones).

As far as I understand these should be the ones defined by Patternfly, but I cannot find where to override them.
I tried editing the file affected by this commit, but without success.

Can you give me some hints?

Thank you very much,

Gabriele

[garrett]

The file you linked is intended to override PatternFly 3 only, to make it resemble PatternFly 4. Much of Cockpit has been ported over to PatternFly 4, so editing that file will have no effect on anything that's in PatternFly 4.

Which colors in particular are you trying to change? Most are represented in CSS variables these days, not just for PatternFly 4, but also for PatternFly 3 and Cockpit custom widgets.

There's one exception: The stripe at the top of the page. That's an accent color tied to the machine it's on, to help you differentiate between multiple machines (if you're using multiple machines). It's blue by default and a custom color can be set when adding or editing machines in the host switcher.

[garrett]

If you're recompiling Cockpit yourself, I'd suggest looking into redefining some of the CSS variables, most likely in page.scss.

If you just want to change the blue of the links and buttons, you'd probably get pretty far redefining these variables in :root:

:root {
  --pf-global--link--Color: #06c;
  --pf-global--link--Color--hover: #004080;
  --pf-global--link--Color--visited: #40199a;
  --pf-global--primary-color--100: #06c;
  --pf-global--primary-color--200: #004080;
}

(The colors included above are the default ones.)

There are a ton more colors too, and you can play around with them in the DOM in any web browser inspector. Changing them in the dev tools should propagate to the page, and for browsers which show changes made in the dev tools, like Firefox, you can then copy them back to whatever file you might be editing.

[gabrielefronze]

Dear Garret,

Thanks for the heads up!
Ultimately, while waiting for your reply, I tried overriding some CSS values as you suggested, with mixed success.

I'll share with you my findings later on.

While I sill need some help with a pair of overrides not working (I don't get why), I reverse engineered a bunch of them which can be overridden from the branding CSS itself. I would be more than glad to add such information in the branding guide.

Cheers

[garrett]

There's also an initiative within PatternFly to handle theming, mainly focusing on a dark mode theme, but also with the secondary intention to reskin the look of PatternFly. However, it isn't ready for use — and it would take some time and effort before it would work in Cockpit, as we're still not 100% PatternFly 4 yet.

(Sorry it took a while to respond. I was on vacation and the others on the team usually don't get into these details about the color and CSS variables and such, as they (rightfully) don't need to. Glad you mostly figured it out in the meantime though!)

Updating the branding guide with these tweaks would be a great idea!

[gabrielefronze]

Hey there,
I'm getting back after putting on an instance of cockpit from my own fork.
Right now I am enforcing my own branding by replacing the default branding with the one I modified myself.
I also needed to modify the page.scss file, as @garrett suggested. Here a snippet of the :root override I came out with:

:root {
    --ct-color-host-accent: #FFA601 !important;
    --ct-color-list-hover-text: #FFA601 !important;
    
    /* Theme color */
    --pf-global--primary-color--100: #fdc55d !important;
    --pf-global--primary-color--200: #FFA601 !important;
    --pf-global--warning-color--100: #eea0d3 !important;
    --pf-global--warning-color--200: #D35FAA !important;

    /*  Link colors */
    --pf-global--link--Color: #FFA601 !important;
    --pf-global--link--Color--hover: #fdc55d !important;

    /*  Inline link colors */
    --pf-c-button--m-link--Color: #FFA601 !important;
    --pf-c-button--m-link--m-inline--hover--Color: #fdc55d !important;

    /*  Nav link colors */
    --pf-c-badge--m-unread--BackgroundColor: #FFA601 !important;
    --pf-c-nav__link--Color: #FFA601 !important;
    --pf-c-nav__link--m-current--Color: #fdc55d !important;
    --pf-c-nav__link--before--BorderColor: #FFA601 !important;
    --pf-c-nav__section__link--hover--after--BorderColor: #fdc55d !important;

    /*  Progress indicators colors */
    --pf-c-progress__indicator--BackgroundColor: #FFA601 !important;
    --pf-c-progress__bar--BackgroundColor: #fadda7 !important;

    /*  Table headings colors */
    --pf-c-table__sort__button__text--Color: #FFA601 !important;
}

Here are some screenshots of the results so far.

I am still trying to override the chart colours.
The only thing I don't really like is acting directly on the page.scss file to override the :root section.
I would rather prefer to be able to do the same via the branding.css instead.

[garrett]

I think you shouldn't need the !important (but perhaps you do here... it probably does depend on where you put it in the file too... if it's at the top, everything below will override it, so it's best set after everything else).

Having a separate branding for custom branding makes sense. I think branding.css is mainly for distribution branding and only for the login page. I'm pretty sure we currently don't have anything for identity branding (aside from the Linux distribution customizations).

---

Note: The color you picked is an obvious difference from the standard blue, but it has accessibility issues due to a lack of contrast. If that's the general color you're going with, I'd suggest darkening it.

• More info about color contrast: https://developer.mozilla.org/en-US/docs/Web/Accessibility/Understanding_WCAG/Perceivable/Color_contrast
• A nice color contrast checker, with demos of how it'd look like in widgets: https://userway.org/contrast/ and it supports specific color combos when linking too. Here's your color combo: https://userway.org/contrast/fdc55d/ffffff
• Another color checker: https://accessible-colors.com/ it's one of my favorites as it suggests similar colors that would pass accessibility guidelines (both AA and AAA). However, it doesn't show example widgets.

You want at least AA compliance. AAA is nice; making it more accessible is usually better, but it does come at a cost at what you can do.

[gabrielefronze]

I'll try without the !important tags, I was just making sure the edits were effective despite the huge css file pattern fly actually generates. But fair enough, if that's not needed then I can get away without that.

Yesterday I experimented a little bit more and I ended up creating another scss file to keep together the modifications to the :root section and to be able to import them in multiple other style sheets.

I still have to deal with it, but I think I can get to a setup where even such information is in the branding css.
I noticed the branding css is indeed very related to the login page but maybe I can elevate that to a stronger effect on the whole application.

Thanks for the heads up on contrast, I'll definitely have a look and try to improve that!

[garrett]

I've opened an issue @ #16359.

(No promises if/when this would be implemented, but I spec'd it out to make it more obvious what is needed, roughly how it should be implemented, and why it's wanted.)

[garrett]

@gabrielefronze: If you want to solve the new issue I just opened, I think it'd be a very welcome addition.

I hope what I wrote in the issue would be a good guide on what should happen. I think you've probably solved most of it by now; it'd just need to be made official by sending a PR and we could finish it up to be accepted within Cockpit by default. (Without your branding enabled, naturally, but your branding would be a great trial run to make sure it works.)

[gabrielefronze]

Sound absolutely good! I'll gladly work on this and go through the PR as soon as I have something I am satisfied with, both from the style and from the "code" point of view.

Thanks!

[gabrielefronze]

@garrett I need an additional suggestion. I don't get if currently there's a style sheet loaded by all pages. I am getting incoherent behaviour when acting on some elements of the page via my custom_colors.scss sheet.
It seems to me my overrides are actually loaded by some pages but not from some other ones.
Thanks!

[garrett]

I'm pretty sure page.scss is loaded by all pages. However, custom CSS that changes variables needs to show up after everything else.

[dgdavid]

Hi guys!

I want to first thank you both for the useful bits of advice and examples you have shared here. Much appreciated! 🙏

I've been playing around with that topic this week and have recorded some ideas and experiments in https://gist.github.com/dgdavid/ec2648c61f63f49a8aa8d9871d2b70f9.

It would be great if you could take a peek at it. Your feedback is more than welcome, even comments calling me crazy for suggesting batch replacements in the final CSS output 🤦‍♂️ 😜 😉

Likewise, let me know if I can help with #16359 in any way. I could collaborate as far as my knowledge and time permits.

Please, excuse me for reusing a discussion marked as answered. I thought that continuing the thread was better, but I can start a new one instead if you prefer.

Regards.

[gabrielefronze]

Hey there!

My company is getting back to this in these days, so I expect to give some updates in the next month. It's definitely a great deal being together on this journey!
We can even find a way to really cooperate into making the styling more open and organised.
Can we get in touch privately with pleasure. 😁

Cheers,

[dgdavid]

Hey there!

My company is getting back to this in these days, so I expect to give some updates in the next month. It's definitely a great deal being together on this journey! We can even find a way to really cooperate into making the styling more open and organised.

Sure! We can help each other on this, but I strongly believe that Cockpit maintainer's insights and guidance would be invaluable in moving the topic forward.

Having said that, I have changed my mind regarding the workarounds previously suggested. I ended up patching all HTML pages for linking a theme-overrides.css file after their stylesheet, which allows following the same branding.css rules (more or less). Thus, you can put your overrides in /usr/share/cockpit/branding/whatever/ and it simply works (except, of course, for third-party Cockpit modules not including the link to the mentioned stylesheet). This approach comes with some advantages, such

• It follows the same rules as branding.css
• It's not needed to patch pkg/lib/page.scss with every new CSS change which also means not recompiling Cockpit each time the theme changes (as long as the theme will deliver as a separate package)
• Does not come with the pkg/lib/page.scss "duplication issue" (all rules declared there are included in each page stylesheet)
• Theoretically, it would be possible to build and deliver the custom theme in a completely separate package, my-cockpit-theme.rpm for example.

Since an example is worth than thousand words, I'll create a pull request against upstream next week if possible. Meanwhile, you can have a look to https://gist.github.com/dgdavid/fa638109082e8a0038722ca917a195fd if curious :)

Can we get in touch privately with pleasure.

Great, thanks. Unfortunately, I won't be available until June 6th. Let's see how things are at that date. Nevertheless, I think using public channels is beneficial not only for the Cockpit community but also for polishing or improving our ideas.

Cheers,

Regards.

[gabrielefronze]

Sounds great!

We should absolutely keep track of anything we come out with here, I didn't suggest to cut out the community of this tool we both love! :)

In private tests I came out with a similar approach and the option to have a separate RPM is awesome and totally adhering to our company "rules".

Sounds good for getting in touch again after June 6th, we can absolutely do that. What I was mainly suggesting was creating a cockpit channel on our slack team to implement some real-time interaction (absolutely not replacing this topic and the official cockpit channels).

Cheers