The forum maintenance reminded me to ask for this:
1 Like
Okay! I think that should be working (tested on the Mac anyway). I changed my setting to light mode, and then enabled the new checkbox to automatically switch. Now the site changes instantly depending on the macOS setting. Pretty nifty, thanks for letting me know!
2 Likes
Wonderful. That was fast. Thank you! 
But I found one small glitch. The code colors don’t match when “Enable automatic dark mode color scheme” is enabled and the OS is in dark mode (as seen in the last row):
Not sure why, the theme colors are correct when either “Light” or “Dark” is set manually. 
That’s strange, seeing as how it is all coming from one CSS file. Must be some caching glitch though; maybe different CSS directives are separate. Try doing a hard refresh (F5 in most browsers).
Doesn’t make a difference, also across browsers (Brave / Chrome, Safari, Firefox). I’m surprised it works for you.
It’s almost as if those values are hard-coded in a place that isn’t “dark mode aware”.
Hmmm…
Light
https://forum.literatureandlatte.com/stylesheets/theme_2.scss
Dark
https://forum.literatureandlatte.com/stylesheets/theme_1.scss
Light (Auto Dark) in Light Mode
https://forum.literatureandlatte.com/stylesheets/theme_2.scss
Light (Auto Dark) in Dark Mode
https://forum.literatureandlatte.com/stylesheets/theme_2.scss (should be theme_1.css)
1 Like
I’ll have to take a look at it tomorrow, but yes, it is weirdly pulling the p>code selector from the light mode theme file. I might be able to work around it by using a variable in both of those places, and then defining the variable in the different themes elsewhere (where it seems to be pulling the data properly). Surely that’s a bug of some sort though; it is a beta build after all.
This is a test of block code.
Blah blah.
1 Like
Only if you have time, it’s not a huge problem. I guess they overlooked this when adding the “auto switch”.
Could be, though it could also be my “fault”; as you probably noticed I’m rather brute forcing that background-color because asking nicely wasn’t working. Might be there is a better and more recommended way of doing things.
1 Like
Yeah, I was wondering what’s so !important, somehow that screams “workaround”. 
Hopefully there’s an easy fix. From my client-side poking it looks like the loading of “theme_2.scss” is hard-coded (the colors are okay, just the wrong file in Dark Mode), maybe you can “just” move that into a “prefers-color-theme logic”.
/note to myself: Remove 
from Stylus later!
All right, so the reason this isn’t working well (in numerous ways, but this is the most obvious), is that this isn’t a dark mode theme switcher, but a palette switcher. Palettes are dirt basic, a dozen colour settings and that is it. From this pool of a dozen, it automatically generates many dozens more variants that are slightly lighter, darker, blended with other colour settings, etc.
But that latter part is beside the point because if I don’t supply my own background colour in the CSS then it doesn’t use either palette, but instead uses the --hljs-bg variable, which is part of the syntax highlighting package, and that is hard-coded with two different light/dark variants.
Therefore I think the only actual solution is to not have a custom background for light mode, so that it handles that automatically for both. I’m not a huge fan of how subtle it is in Light Mode, but I can’t think of any other way around it.
1 Like
I see. Hmmm. Not sure, if this is any help, but yesterday I added the following code to Stylus (the browser addon):
@media (prefers-color-scheme: dark) {
p>code, li>code {
color: #00FF80;
text-shadow: 0 0 5px #008040, 0 0 10px #008040, 0 0 15px #008040;
background-color: #000000 !important;
border: 2px dashed #008040;
padding: 3px 6px;
border-radius: 6px;
}
}
which results in:
and that likely works in Discourse, too. Just make sure it’s the “last style” and doesn’t get overwritten by some other CSS (computed or not). And choose different colors. 
1 Like
That’s a good idea, but the problem with that approach would then be people using dark/light mode settings in their browser (or system I suppose) but not using the flag on the site, and are using light mode in the forum out of preference. In that case, the prefers-color-scheme block triggers in light mode because the browser is hinting it should use dark, and you end up with black-on-black-ish text in light mode for code spans.
At least, I think that’s going to be a hard problem without a solution. In my brief testing I couldn’t get a satisfactory result across the board.
1 Like
I don’t have this issue with the code posted above.
- Light Theme (without flag), OS Light Mode = vanilla look
- Light Theme (without flag), OS Dark Mode = hack applies
- Light Theme (with Auto-flag), OS Light Mode = vanilla look
- Light Theme (with Auto-flag), OS Dark Mode = hack applies
- Dark Theme (without flag), OS Light Mode = vanilla look
- Dark Theme (without flag), OS Dark Mode = hack applies
- Dark Theme (with Auto-flag), OS Light Mode = vanilla look
- Dark Theme (with Auto-flag), OS Dark Mode = hack applies
Light Theme (without flag), OS Dark Mode = hack applies
Isn’t that the problem though? If the conditional applies then you get strips of black everywhere spans are used, in light mode otherwise. That’s what I got anyway, in a Chromium-based browser set to dark mode (not OS auto like you say here, but that should be the same result).
1 Like
This combination gets me:
I think the reason why this looks out of place, but is still legible, is the definition of the foreground / text color. Otherwise it would be dark on dark under those circumstances.
So yes, not a good solution.
It’s almost like a passive-aggressive approach by the Discourse team. I can’t think of any worse way to implement styles.
Yeah, I think on posts with lots of these, that would be a bit much to look it and would strain the eyes. It is only one (perhaps even uncommon) combination though, so I don’t know, maybe it’s worth it until someone complains. 
It’s almost like a passive-aggressive approach by the Discourse team. I can’t think of any worse way to implement styles.
Ha, well I get where they are coming from in the sense that themes are way more than just CSS and some colour settings; they can include Javascript, fundamental HTML changes, etc… So it would require a hard refresh, which is why changing the preference itself reloads the page. Not the kind of thing you’d want happening out of the blue in the middle of writing a post, at 19:32 or whenever the OS decides it is now night.
1 Like
I agree, but then… let’s say it’s always the whole nine yards, all or nothing, full reload. But for some reason you don’t get matching code colors. Why is that the only thing they left out. Everything should include everything.
The rationale there is probably that syntax highlighting requires a much more controlled environment than what the dozen colour settings give one, and to ensure all of the many different possible colours look good in both light and dark mode; so it makes sense to keep the background separate from the custom palette and stick with neutral tones for that.
Now why spans need to match the block background is something I’m less clear on. That seems to me more an opinion than a practical solution to a problem, because I don’t think it is possible to invoke syntax highlighting in spans.
1 Like
Yeah, my Stylus code doesn’t even modify code blocks.
So, basically you need to go the other way round. Don’t rely on the browser / CSS switch. Hard-wire the colors into each theme. (It’s kind of back to square one = stop Discourse from loading the wrong colors. Sigh.)