Color schemes should be specific to a single theme


(Erlend Sogge Heggen) #1

There are two hairy issues with our current implementation of color schemes:

  1. color schemes are globally available to every theme and are not theme specific.
  2. offering more than one user-selectable color scheme for a theme requires you to “duplicate” the theme as a separate entity

Neither of the above should be true.

It is far more common for a site (or app) to offer multiple color schemes (most commonly one light and one dark) rather than multiple themes; practically all companies will just want to maintain a single theme that is tailored to their branding.

The way we handle color schemes right now is confusing. Selecting a color scheme in our wizard will create a new-standalone theme for that color scheme. To find those other color schemes I need to re-do the wizard. What’s more, once I’ve redone the wizard and selected a new color scheme, I’ve actually just added an identical theme which happens to have a different color scheme set as its default:

While the theme “Latte” has the default color scheme of “Latte”, I can set that color scheme to “Neutral”, “Light”, whatever.

“Latte” shouldn’t be a theme. It should be a color scheme specific to our default theme, which it was specifically designed for.

The color schemes editor should look more like this:

Just to reiterate: Color schemes should be theme-specific:

  • Our default theme should have its own distinct color schemes
  • Material theme should have its own distinct color schemes
  • Classic theme should have its own distinct color schemes
  • etc.

How to use theme color scheme
Better color schemes selector
(Jeff Atwood) #2

Hmm honestly I can’t even follow this topic, because it is too confusing. @sam how did we get into such a ball of confusion here?


(Kris) #3

I don’t think color schemes need to be tied to themes, color schemes just need to be user selectable (having a default scheme for a theme might help).


(Joe) #4

I think tying color schemes to the themes they come with is a requirement for user selectable color schemes. This is an easy way to de-clutter and only show a list of color schemes the theme is designed for in the color scheme selection interface.

If users are allowed to select a color scheme, and all color schemes are available on all themes, then a user might have the Classic theme active but with the Material Red color scheme which is not ideal.

This feels like a tiny bug to me. We added the new color schemes to the wizard but they won’t show on the theme list in the admin until you choose them in the wizard.

So we have this:

And the new ones are only added after you select them in the wizard (one by one)

Whereas I think we should just show all of them right off the bat like we do with the dark theme

Going further, I believe what @erlend_sh wants is to not have these here:

Since those are all the “default” theme but with different color schemes. They should all be here:

Along with a new way of marking which of these should be user selectable for the default theme.


(Kris) #5

This feels more restrictive than it needs to be to me… If a theme works well with existing color schemes, why restrict it? It’s possible at some point we could allow users to use their own color schemes too.

I guess then there’d also be the question of who defines what’s an allowable color scheme for a user to select. Would they be restricted to what ships with a theme in about.json? Could an admin override this and add their own color schemes to a theme’s whitelist?

I think I’d just prefer setting a default color scheme for a theme, which is automatically selected when you switch to the theme. The user could then select any color scheme that’s available.

I think this is fine until we have user-selectable color schemes, because then we could put them in the color scheme list.

Right, I agree here. I think it’s this way because we currently ship with the Default theme (light) and Dark theme (which is just a color scheme). User-selectable color schemes would fix that too.


(Erlend Sogge Heggen) #6

Right, so the first order of business I skipped past here is: Make color schemes user-selectable.

Well it’s our responsibility to present solid defaults and not an overwhelming amount of mediocre options.

If I’ve made a theme that just won’t look well with anything other than its stock color schemes, I’ll want a config option that ensures no other color schemes will show up in the color scheme selection for my particular theme.

If we can figure out sensible controls for this I’m fine with color schemes being globally (optionally) available, but it strikes me as a non-trivial problem. The much simpler solution is to make color schemes theme-specific and leave it at that, at least until we’ve

I would not prefer that. Any theme that goes the extra mile should come with at least two default color schemes: One light and one dark.


(Sam Saffron) #7

This is already the case though, its just that the admin UI is not ideal. My vote here is to put this whole thing on ice till @Osama is done with the user selectable theme components and splits up components from themes properly.

Introducing UI that allows you to have N selectable color schemes is complicated on multiple fronts.

  1. What if a color scheme exists for a theme and should not be user selectable? Do we need to add one more tick box there to specify this?

  2. How do we copy schemes between themes?

  3. What is the name of this “merged entity”? “Default - Light” may work in English but localizing this is annoying and building a system for localizing this is complex.


(Jeff Atwood) #8

We need to simplify all this, not make it more complex.


(Sam Saffron) #9

My call is that adding “flavors” to the current theme system is adding complexity. When you look at a theme now you know it is 1 thing. The proposal here make you look at a theme and it could be 8 things.


(Erlend Sogge Heggen) #10

I don’t think we are understanding each other correctly here but let’s put this on ice until @Osama finishes up with theme components.