Fix darkmode presentation

[nigelmegitt]

Dark mode somehow got broken in the last 7 months since I last fixed it.

The current toggles don't fix the media query for prefers darkmode, but just add the darkmode class to the body element. Explicitly set the colours when the darkmode class is added to body, horribly duplicating the existing @media (prefers-color-scheme: dark) rule but using CSS nesting.

This is a hack but does make all the text at least readable in dark mode.

---

Preview | Diff

[nigelmegitt]

@himorin I suggest we merge this and also merge it into the CR branch as soon as you can approve it, because the current CR version is broken now in dark mode.

Actually it's still broken but not quite as badly - the dark mode toggle tries to remember the setting but doesn't re-apply it on page load, you have to explicitly click it to Light or Auto and then back to Dark to get the rest of the page to load properly, but that's a problem with someone else's script - probably fixup.js, I imagine.

[himorin]

if we want to introduce duplicate CSS definition from prefers-color-scheme to .darkmode, I suppose we should do the same thing for light with default mode as darkmode..
I believe it could be performed with @media (prefers-color-scheme: light) with :not(:has(.darkmode)), but haven't checked yet.

[nigelmegitt]

if we want to introduce duplicate CSS definition from prefers-color-scheme to .darkmode, I suppose we should do the same thing for light with default mode as darkmode.. I believe it could be performed with @media (prefers-color-scheme: light) with :not(:has(.darkmode)), but haven't checked yet.

I don't think we need to - it's the default behaviour and seems to work fine without doing that.

[nigelmegitt]

I suppose we should do the same thing for light with default mode as darkmode..

@himorin just to add, if you have any reproducible steps that show a problem with the light mode styling not being applied in light mode, please tell me! I tried all the ways I could think of and could not create a problem with the CSS as it is in this PR.

In Firefox's dev tools it shows that the @media (prefers-color-scheme: light) {} block rules are being applied in light mode.

[himorin]

if we want to introduce duplicate CSS definition from prefers-color-scheme to .darkmode, I suppose we should do the same thing for light with default mode as darkmode.. I believe it could be performed with @media (prefers-color-scheme: light) with :not(:has(.darkmode)), but haven't checked yet.

I don't think we need to - it's the default behaviour and seems to work fine without doing that.

I wonder what will happen when 1) browser is configured with dark mode as default, 2) user manually select light via left lower selection panel (similar to forced dark mode)...
also I found I was wrong that it's not selectable just with :not(:have())... (how respec itself is doing....!?)

[nigelmegitt]

I wonder what will happen when 1) browser is configured with dark mode as default, 2) user manually select light via left lower selection panel (similar to forced dark mode)...
also I found I was wrong that it's not selectable just with :not(:have())... (how respec itself is doing....!?)

Aha! Yes, that does have a problem, I didn't think of setting it at the browser level, before I was just setting it at the OS and the page level. I will add a fix for that. Thank you!

[nigelmegitt]

@himorin I think that's fixed now: are you able to check and confirm?

[gkatsev]

Using https://github.com/Cimbali/toggle-dark-mode (very useful to play around with things)
here's how the preview looks like with the browser (Firefox, in this case) in light and dark modes and forcing light or dark mode via the toggle
browser set to light mode, page set to light mode

browser set to light mode, page set to dark mode

browser set to dark mode, page set to light mode

browser set to dark mode, page set to dark mode

I think a lot of spec pages aren't set up to work properly with a mismatch between the page selection and the browser selection. When they match, this works great.

[nigelmegitt]

Thanks for that @gkatsev - did you try toggling the light/dark selector at the bottom of the sidebar back and forth after loading the page? I think there's an issue with the following sequence, which is not something we can fix:

1. Open page in a tab or window
2. Switch to dark mode using sidebar widget
3. Close tab or window
4. Open a new tab or window, open page - at this point the widget shows dark mode is selected (it must have saved some user setting somewhere) but the page doesn't look like it is in dark mode
5. Toggle the widget to light mode and back to dark mode - now the page looks like it is in dark mode

[gkatsev]

I can reproduce that, but it seems to only happen when the browser is in light mode and choosing dark mode on the page toggle.

[nigelmegitt]

It's also worth noting that what that sidebar toggle does is just adds or removes the darkmode class on the <body> independently of the browser's dark mode setting. So there are permutations of the media query result and the darkmode class being present or absent - in short, I'm not at all surprised that you found 4 distinct presentations, and I don't think it's worth trying to fix for all of them, because it looks like a broken pattern to me.

Having said that, this PR does set the styles based on both the media query and the darkmode class so I'm a bit disappointed that it still has problems. It doesn't control the table of contents of main body styles though: those are in the domain of the W3C stylesheet(s).

[gkatsev]

ah, can trigger it also by selecting dark mode and using the extension to toggle the browser darkmode setting. Guess it's a mismatch between respec's prefer-color-scheme: dark and .darkmode.
It's probably possible to fix, but maybe not a blocker for this PR

[gkatsev]

The full solution likely involves dealing with the media query and the css class and fixing each permutation

[nigelmegitt]

The full solution likely involves dealing with the media query and the css class and fixing each permutation

Also fixing the W3C stylesheets to do the same.

[nigelmegitt]

It's probably possible to fix, but maybe not a blocker for this PR

Not only not a blocker for this PR but also not a blocker for CR publication, assuming this PR gets merged.

[nigelmegitt]

Are you able to get this into the CR for tomorrow, @himorin ?