Missing or wrong colours – how to improve existing palettes?

While tuning the design of tiddlers in my Tix project I missed some colours in some of the palettes. Others have been missing some colour definitions in the Twilight palette I once contributed. (I think there was a “call for palettes” or something at that time.)

How can we make sure that palettes are as complete and up to date as possible? Authors of plugins and themes as well as TW users might expect their wikis and plugins to work with any palette. But we can never be sure.

Example 1:

In $:/palettes/SolarizedDark the colour for dirty-indicator is set to inherit. This results in the save/checkmark button never changing colour and I might forget to save. The palette has no author field so it might be a core palette (created by @jeremyruston)?

A solution that works for me is

dirty-indicator: #f23670

But I can never know if other users of that palette can live with that. And of course, if an author can be found, he or she should decide. (It might even be an undocumented feature.)

Example 2:

In my own palette Twilight the colour defined for muted-foreground is rgb(255, 255, 255) – this equals white and in a dark layout it stands out more than any other colour. An error obviously and not muted at all.

My preferred value would be

muted-foreground: #8c8d8c

But I never found out how to contribute via github in a proper way, so I will not try that myself.

Are there any ideas or plans for a “colour palettes upgrade” or a new “donate your palettes” initiative?

All the best,


This is not related to your question, but the below palette generator is an amazing tool



Thanks @telmiger

That bug seems to date back to the original submission of the palette:

The <<colour>> macro does have a couple of fallbacks if the required colour isn’t found in the selected palette:

  • first it looks in the “vanilla” palette
  • if it is not found there, it looks for a tiddler titled $:/config/DefaultColourMappings/<colour>

The idea was that when we introduced new colours to the default palette we could add a default colour mapping to ensure a sensible default with palettes that don’t include the new colour.

I think one can make an argument that the ordering should be different, with the colour mapping searched before the vanilla palette.

I’m sure that me or others could prepare PRs on your behalf for those kinds of changes.

No, but I welcome new palette contributions. Like lots of us, I regularly set up new TWs and it’s nice to be able to make them look different without getting bogged down in making a custom palette.


Found a bug in $:/palettes/GruvboxDarkand $:/palettes/Nord regarding button colours: Critical colours are the same as page-background – that can render borderless and boxed buttons/button text truly invisible – at least in the sidebar.

A better choice would be

sidebar-button-foreground: <<colour sidebar-foreground>>


button-foreground: <<colour foreground>>

The suggestions above are not solving the problem. Reason: Button colours for background and border are missing in Nord (maybe in other palettes too?).

So my conclusion for the moment is: Much more time would be needed to resolve such issues. The fallbacks built into TW mentioned by @jeremyruston would have to “analyse” colours that are defined (in this case: button-foreground) in order to calculate readable missing colours (in this case: button-background) with sufficient contrast. But even then, dependencies in boxed and rounded buttons differ from borderless buttons and a dark sidebar combined with light tiddler background can increase complexity even more.

For the development of palettes a test suite showing buttons of all types on all possible backgrounds would be helpful.

For developers of solutions like @Mohammad my advice would be to restrict user options (as done with hard coded button styles).

I will go with a (in some cases) low-contrast set of colours for Nord and go back to my other projects.

button-foreground: <<colour foreground>>
button-background: <<colour background>>
button-border: <<colour muted-foreground>>

Hi, Have a look at this one


I always end up adjusting the palettes in my own TW because of missing or troublesome values.

Could a formatting guideline be recommended for making palettes, like what values should be included, and what format to save the colors as?

I often use the hex code for colors so I can apply alpha (transparency) by using <<colour primary>>50 which roughly turns it to #6699ff50

Edit: does tw5-captivate set a color-scheme? I noticed when changing from light and dark themes, the scrollbars were staying with a light theme.

Just my thoughts!


Nice trick! I usually attempt to use palette specifications rather than hard-coded values within my custom stylesheets, and splicing in an alpha value promises to provide further flexibility within this approach.


1 Like

This has been raised several times. Colors in Tiddlywiki is really tough to manage! Specially if you want to create something to work with all palettes.
I believe one of next release should only focus on palettes and themes and resolve issues and a little standardize the creating of palettes and themes.
I hope @jeremyruston consider this.

1 Like

I agree 100% with this! I like how they are handled and how flexible they are, but I also feel like having minimum required colors is a good thing too. If one palette uses tiddler-border but another does not, it can lead to some conflicting designs.

it would be really neat if the color palette showed all the colors being used in it, like a circle with the color and then the value next to it. hmm… :thinking: things for me to tinker with in the future!

That’s right. … After I did finish the work with the PaletteManager, it should be relatively easy to bring all the default-palettes up to 1 “working” standard. … After that’s done… we can go on


Hi Mario, it’s me again :wink:

Using your preview of the Palette Manager I have optimized 8 of the standard TW palettes to my liking, 6 of which i would deem usable for people like me who need good contrasts.

The results can be found here: TW News — What’s new since TiddlyWiki 5.1.0

Based on your previews I built a Test Suite tiddler, maybe that is of interest for you too.
Thanks again for this amazing tool!

All the best,


Thomas - Thank you for the nice feedback.

I’ve seen your other post at: Palette Manager -- Feature Complete - #14 by telmiger but I did not have time to have a closer look.

I’ll investigate the difference between my “vanilla” CSS settings used for the Palette Manager and the new TW-version. As far as I can remember it had something to do with the “big green download button” and the “page sidebar buttons”.

I’ll need to test them and compare with my own experiments.

A pull request with some updated palettes for tiddlywiki.com is long overdue.

To make it happen imo it’s needed to create several demo-wikis, that have the new and the old palettes installed, so other users and Jeremy can easily compare them, without a lot of time investment.

The PR on the other hand only needs the new palettes.

So the time needed to prepare the previews and the PRs is relatively heavy, compared to what is seen in the end-result. …

You probably know, how much time is needed to tweak one colour value, without breaking something else, that also uses that colour :confused:

1 Like