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 supports this feature in Tiki 26; this page is a report on the path toward 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. This was later addressed and is no longer an issue.

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
}

Please have a look at one of the theme's _css-variables.scss files to see how the combinations of light and dark navbar color settings and light and dark color mode options work together. This varies somewhat depending on the theme and desired appearance.

Subsequent steps

Following the alpha and 5.3 releases, these were some tasks addressed:

• Rechecked 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?
• Rechecked color changes in nested page objects; this issue was on the radar so was expected be resolved. Update: This was improved/fixed in alpha 3. For example, cards without a background color inherit the page color as expected.
• The details of Tiki's implementation were decided:
  • A new Color Mode Switch module was made to provide the color mode switch to the site user.
  • The module parameters, still to be done, should be in a comma-separated list because the modes are likely to vary from one Tiki site to another.
  • Essentially every theme in the package got the alternative color mode files but some (dark themes) exhibit little or no change in the switch.
  • About how color modes work regarding child themes, it seems the child theme also need dark variables, etc. if it specifies colors subject to switching.
• Still being thought about:
  • 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.