History: Implementing Color Modes in Tiki

Test setup

Tiki will support this feature in an upcoming version; this page is a report on the current status of the Tiki implementation of Bootstrap color modes. To do some testing, etc., in a new Tiki 25 instance, I () replaced the Bootstrap 5.2 files in the vendor directory with manually downloaded Bootstrap 5.3 alpha 1 files.

The switch

For the color switching, Bootstrap uses some JavaScript on their example page and offer it to people to use, which is what I did, putting it in a PluginJS in a wiki page which I then use for a menupage-type module assigned to the top module zone at the page top where we usually see default mode / dark mode site color switches. This was just a proof of concept and a proper "Switch Color Mode" module should be made eventually.

Compiling glitches and results

Trying to compile a Tiki theme ("Default" for the first tries) with the new files resulted in a few compiler errors due to an outdated color statement (more information later). However, while the new default.css could be compiled and it worked, it also contained uncompiled SCSS variables. I didn't track down yet what caused this but will check again with new Bootstrap releases as they come out.

These color modes are produced by compiling "dark variable" (or other custom color set) alternatives to the default colors of the theme. One way to organize this is for the theme to have a variables-dark.scss file to contain them. Then each equivalent of a default variable is appended with -dark (again in the case of a "dark" color mode).

Bootstrap issues

In my test, I could edit the existing variables in the alpha package and see the results in my site, but adding new variables didn't work. Specifically, the Amelia and Boosted themes need $card-bg-dark but defining this and compiling didn't succeed in overriding --bs-card-bg . I did an online search and found other people running into the same issue: https://github.com/twbs/bootstrap/issues/37799. I assume this will be addressed so I'll check again on this later.

Compatibility with Tiki CSS variables

One thing I was curious about is how the new color mode feature gets along with the Tiki CSS variables method used for the top and topbar module zones/navbars, which are a Look & Feel theme option. For example, if the site admin has set "Light" for the site's navbars (so navbars have a light background color and dark foreground colors), what happens if color modes are available and the user switches to "Dark"? Does it override the admin option? The answer is yes, it does, or anyway it can if desired. The key is to use the color mode as the selector like

[data-bs-themes="dark"] {
    --tiki-top-light-bg: #000; // light option gets a black background in dark color mode
{

Next steps

So, going forward, following new alpha and beta release, these are some tasks ahead:

• Recheck compiled CSS files for uncompiled SCSS variables. If they aren't reported by anyone else, is there a problem in Tiki's implementation to locate and fix?
• Recheck color changes in nested page objects; this issue is on the radar so should be resolved.
• Decide on the details of Tiki's implementation:
  • Presumably a module would be displayed to provide the color mode switch to the site user. Would there be other methods, or is this enough?
  • Create this module. Its parameters would be in a comma-separated list, I imagine, because the modes are likely to vary from one Tiki site to another.
  • Does every theme in the package get alternative color mode(s)?
  • Is it possible to provide a global dark mode stylesheet that can impose the dark mode regardless of the theme being used?
  • What color modes other than dark, if any, should be provided? Accessibility guidelines regarding visibility, etc., should be the guide here.
  • How should dark themes be treated? Do they get a "light" alternative? This raises the question of what is the rationale for color modes — strictly usability, or style variation also? It isn't hard to imagine seasonal or event-related color modes, and so on, but this would be left to Tiki website operators to pursue, I imagine.