I’m experimenting with color schemes that have a dark header background, but a light site background.
Is there a way I can mark these color schemes so they pick up the dark mode logo anyways? (since it has light text)
I’m experimenting with color schemes that have a dark header background, but a light site background.
Is there a way I can mark these color schemes so they pick up the dark mode logo anyways? (since it has light text)
Hmm, not easily. Our calculation for dark mode logos is based on whether the whole color scheme is considered dark, and for that we compare the brightness of the primary and the secondary color. That calculation happens here in the code.
Your use case doesn’t quite match that scenario, though. You could write a theme override of the logo that defaults to the dark one, but then you’d need users to switch themes as well as color schemes… tricky. I’m guessing you want to allow users to select multiple color schemes, right?
Yes, I’m running a single theme instance and I’d like to keep it that way. It’s much simpler for the users.
I’d be happy with some hacky solution, like being able to inject custom CSS/JS based on the color scheme.
But ideally, each color scheme should have an option—in my opinion—to determine whether it picks up the dark or the light logo. Deciding automatically based on the base background color doesn’t work, exactly because the header background could be completely different.
That may be desirable, I’m not entirely sure really, but even if it is, it’s a tricky thing for a color scheme to control. In a sense, having a color scheme pick its logo would mean the color scheme would reach out too much outside of its own scope.
This complicates any possible hacks too. We don’t currently have a way to add CSS or JS based on a color scheme’s name or id.
hmmm
what about specific color in the theme palette? like a conditional CSS for the logo based on the header color?
I really agree with that.
On my forum we have a pink colorscheme. It has a pink title bar and a light secondary color.
In the Light colorsheme, the title bar looks like this:
In the pink colorshceme, we expect the logo to look like this, just like the dark mode logo:
But what we actually get is this, Because discourse simply regards it as adapting the light mode logo:
In the end, we used some less elegant theme components to make the logo influenced by the header color. We are slightly distressed by the automatic determination of how dark and light color modes affect the logo.
I mean, it doesn’t seem to me like that’d be reaching outside of the scope of a color scheme.
I’m not talking about custom per-color-scheme logos, I’m just asking for a setting to determine whether the color scheme should summon the light mode or dark mode logo, instead of it being automatically determined. Automatic detection can still be the default behavior.
I’m imagining a dropdown called Logo Detection with options Automatic, Light, and Dark. Then whatever code you have that makes the determination, can see that checkbox and check the background color if it’s automatic, or just pick the specified logo.
That seems to me like information that’s semantically relevant to a color scheme, and not at all a major feature.
I’d love if you could share your solution, @Lhc_fl. It’d at least be a temporary workaround for me.
If you can explain more how that’d work, @Lilly, I’m all ears.
We made each colorscheme into a theme separately…
Ah, too bad. Thanks.
Yea i did the similar as @Lhc_fl for my forum, but I change header color and logo by category in two dark and light themes. My users aren’t tech inclined and found the light - dark option in a theme to be confusing, so I use light and dark themes instead. I think that would be my suggestion since you are only working with one actual theme. the sidebar theme toggle TC makes it easy for users to switch.
If I wanted to make a feature request, is that a thing for a thread in feature?
yes it is or we could move this topic to feature
I think fresh feature or ux requests are preferred, if possible, rather than sliding over a support topic. That way you can frame what you want properly in the OP, flesh out a strong use case, and fold in/summarise anything you may have learned while exploring the idea in a support topic.
Ultimately, the stronger your case the more likely it is to be considered for development time.
I’ll make the new topic and reframe it.