History: Implementing Color Modes in Tiki

Of course Tiki already offers site users the ability to switch themes, and some of these are "light" and some are "dark", if the site admin allows users to change the site theme for their own use, and assigns the "Switch Theme" module for users to switch with. But what the color modes feature does is enable immediate color palette switching, without a page refresh, using the same theme but with alternative color values, so this complements and extends Tiki's current options. Also, The Bootstrap color modes feature respects the prefers-color-scheme setting in the user's browser so the Tiki site will conform to that setting with no user interaction needed.

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 release 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 Tiki themed (Amelia, Boosted, and 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 some 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, especially after most-recent Bootstrap alpha releases. If they aren't reported by anyone outside of Tiki, 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. Update: This is improved/fixed in alpha 3. For example, cards without a background color inherit the page color as expected.
• 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? (Tentative answer: It might be possible, but maybe isn't practical. The active theme needs a dark variant. Anyway this is the most straightforward implementation.)
  • 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.
  • How does color mode work regarding child themes? Does the child theme also need dark variables or does it inherit the effect from the parent theme? (It seems that if the child theme specifies colors to override the parent theme, then it will need to specify dark mode colors also.)