The relevant “auto” setting for browsers just turn on dark mode in the evenings and light mode during the day. That’s not really expressing a preference.
I think it is a strong preference, which is why people who accidentally enable it or forget they enable it complained so much when we defaulted to ‘auto’ on Gwern.net.
I am assuming you are being sarcastic and are hence agreeing with me?
I agree, indeed my experience with websites doing the auto thing is mostly that it’s frustrating and I don’t want it, and I expect quick user complaints. At least MacOS pushes users to activate it, and I had it active for a while, but eventually overwrote the setting on almost every website that lets me choose between dark and light mode to the version I want to see in a stable way, usually after a pang of frustration and disorientation as suddenly this one website looked different at a time that seemed random to me.
I would be happy to take bets we would quickly get tons of complaints.
This is exactly how I feel when light mode happens at all ever. Please give me the ability to set my account to dark mode across all devices. Please make light/dark a prominent ui switch for all new users. I don’t care if it’s pretty as much as I care that it’s dark. I agree auto is usually not user preference, despite suspecting it’s best for circadian rhythm. But dark is a common strong user preference and I generally quickly leave sites that don’t honor it, and I find it frustrating to have to argue this hard to get you to consider what most software now has as basic functionality (dark mode setting honored by default and synced across devices if changed).
I would implement this and pr it if I understood the codebase well enough, I mean to sit down and get up to speed at some point.
Yeah, agree, but are we not doing this? I think we currently store it per-device, but like, you can just switch to dark mode on all devices?
Or do you mean we should respect an explicitly set browser preference for “dark”? I don’t actually know whether that’s possible while also not following the “auto” setting.
Or do you mean we should respect an explicitly set browser preference for “dark”? I don’t actually know whether that’s possible while also not following the “auto” setting.
Indeed this is not possible, since there is not actually such a thing as an “auto” setting as far as CSS is concerned, but rather simply a system where the prefers-color-scheme media query matches the light value by default, but will instead match the dark value if the browser is commanded to make it so (either manually by the user or automatically by the system). An “auto” setting exists on the system level, and can exist on the website level (as on gwern.net), but not on the “intermediate” level of CSS and browser implementation thereof.
I believe last time I asked about it, which I think was about 6 months ago, you said something that I remembered as approximately that storing it clientside was the only available option for reasons I don’t remember, and that the cost that sometimes the browser forgets clientside settings is just one that dark mode users will have to bear. that takeaway was frustrating and has left me wanting to push about this. it’s entirely possible I misremembered.
The setting is saved by a cookie, which is the same way we store your login token information. I.e. if someone loses their theme cookie, they very likely would also be logged out, so we really can’t do better than that kind of setting (we could make it so that we automatically restore your preference when you log in again, but that seems like it doesn’t really change the basic experience).
I found at least one repro: set dark mode, edit your user settings, tada light mode. I thought I remembered it resetting to light mode without logging me out or a user setting edit, though. I could believe it’s not the storing-it-clientside that’s causing the resets. I haven’t seen as many for a few months, not sure why.
My preference, by default, is something I communicate through the browser because the browser forwards on my light/dark preferences to websites.
In general, I want websites to do whatever my OS is set to do by default.
The relevant “auto” setting for browsers just turn on dark mode in the evenings and light mode during the day.
This is what Macs do by near-default, but some people use dark mode on 24⁄7 and some people use light mode 24⁄7. It’s not what all browsers+OS setups do.
Yes, that is what I meant. At least Macs do this by default, to the frustration of a non-trivial fraction of users who are now half of the time presented with visual designs that are half-baked, inadequate and barely tested, because realistically maintaining both a dark mode and a light mode design for a website is very hard.
Human color and space perception doesn’t work symmetrically across light and dark contrasts, so a well-designed dark website and a well-designed light website just look very different from each other on many dimensions. You can of course do it with CSS, but we are not talking about just inverting all the colors, we are talking about at the very least hand-picking all the shades, and realistically substantially changing the layout, spacing and structure of your app (so e.g. you don’t end up with large grey areas in a dark mode setting, which stand out vastly more in dark mode than equally high-contrast grey sections in a light mode).
You can of course do it with CSS, but we are not talking about just inverting all the colors, we are talking about at the very least hand-picking all the shades
I recommend my color-scheme-convert.php to automatically convert entire style sheets to a dark color scheme and perform the requisite gamma adjustment. (Which is to say, this script is specifically designed to solve the “Human color and space perception doesn’t work symmetrically across light and dark contrasts” problem.)
It’s what we use to auto-generate the dark mode styles for gwern.net, and is also used for the same purpose in PmWiki.
(Some additional hand-adjustments may be necessary for some elements. However, the script dramatically reduces the workload of doing the conversion, and allows the great majority of it to be automated.)
FWIW, my impression is that while the gwern.net dark mode was a ton of work to create, due to requiring a total refactoring of the CSS and deal with the flash-of-white issue and figure out the correct three-mode behavior, and create tooling like the color conversion script or needing to create InvertOrNot.com for acceptable images, or tweak the syntax highlighting colors to look right in dark-mode… But once we finished paying all of that, the maintenance burden has been relatively small. I have to patch up the occasional image not inverting right and we have to occasionally special case some Wikipedia popups CSS, but it’s on net less effort than much of the website (eg. Apple device support, or the local archive system, are perennial hassles).
The gwernnet dark-mode is pretty good engineering work overall. We should’ve done a design-graveyard writeup to explain not just how it works (non-obvious) but the problems with the more obvious approaches and what problems we had etc. I fear it might be too late to write it now even if we had the time...
I think Gwern.net lends itself somewhat more to the maintenance burden being small. As one example, LessWrong for much of its UI leverages half-transparent images that fade to a white background. Making them be harmonious for dark mode basically means making two images each time.
For example, see this Sequences Spotlight in dark mode:
The image borders are exposed, and the white fade does not work. Compare to the fully functional light mode:
For most things like this we have a pass that tries to edit the images to properly work in both light and dark mode, but it requires a decent amount of artistic judgement each time.
The image borders are exposed, and the white fade does not work. Compare to the fully functional light mode:
To be honest, I don’t like the light-mode example either. I think it’s bad to have your text visibly overlapping like that. (If I made an image which I had put .float-right .outline-not on to get the same effect on gwernnet and I saw your ‘good’ white-mode version, I would be immediately complaining to Obormot about his CSS being busted.) So in this example, isn’t a lot of the problem that the UI elements are overlapping so the text is spilling over onto the scales and blocking the wires etc, and the dark-mode merely exacerbates the problem and fixing the core problem would also fix the dark-mode issue?
Nah, the problem isn’t the UI elements overlapping the text. I just happened to choose an image that also had other issues. You would still end up with an ugly fade and a harsh transition unless someone noticed in time and uploaded a new image, even if the image was more properly placed on the right edge of the spotlight item (and separately, I think the image overlapping a bit with the text is basically fine and I consider it less of an issue, but that seems orthogonal to the point).
Human color and space perception doesn’t work symmetrically across light and dark contrasts, so a well-designed dark website and a well-designed light website just look very different from each other on many dimensions. You can of course do it with CSS, but we are not talking about just inverting all the colors, we are talking about at the very least hand-picking all the shades, and realistically substantially changing the layout, spacing and structure of your app (so e.g. you don’t end up with large grey areas in a dark mode setting, which stand out vastly more in dark mode than equally high-contrast grey sections in a light mode).
I’m hoping the negative agreement karma for the parent comment isn’t for this — it’s just for “maintaining both a dark mode and a light mode design for a website is very hard” (emphasis added, as distinct from creation).
The above blockquote makes me want to say to the studio audience “Why are you booing — he’s right!”.
The relevant “auto” setting for browsers just turn on dark mode in the evenings and light mode during the day. That’s not really expressing a preference.
I think it is a strong preference, which is why people who accidentally enable it or forget they enable it complained so much when we defaulted to ‘auto’ on Gwern.net.
I am assuming you are being sarcastic and are hence agreeing with me?
I agree, indeed my experience with websites doing the auto thing is mostly that it’s frustrating and I don’t want it, and I expect quick user complaints. At least MacOS pushes users to activate it, and I had it active for a while, but eventually overwrote the setting on almost every website that lets me choose between dark and light mode to the version I want to see in a stable way, usually after a pang of frustration and disorientation as suddenly this one website looked different at a time that seemed random to me.
I would be happy to take bets we would quickly get tons of complaints.
This is exactly how I feel when light mode happens at all ever. Please give me the ability to set my account to dark mode across all devices. Please make light/dark a prominent ui switch for all new users. I don’t care if it’s pretty as much as I care that it’s dark. I agree auto is usually not user preference, despite suspecting it’s best for circadian rhythm. But dark is a common strong user preference and I generally quickly leave sites that don’t honor it, and I find it frustrating to have to argue this hard to get you to consider what most software now has as basic functionality (dark mode setting honored by default and synced across devices if changed).
I would implement this and pr it if I understood the codebase well enough, I mean to sit down and get up to speed at some point.
Yeah, agree, but are we not doing this? I think we currently store it per-device, but like, you can just switch to dark mode on all devices?
Or do you mean we should respect an explicitly set browser preference for “dark”? I don’t actually know whether that’s possible while also not following the “auto” setting.
Indeed this is not possible, since there is not actually such a thing as an “auto” setting as far as CSS is concerned, but rather simply a system where the
prefers-color-schememedia query matches thelightvalue by default, but will instead match thedarkvalue if the browser is commanded to make it so (either manually by the user or automatically by the system). An “auto” setting exists on the system level, and can exist on the website level (as on gwern.net), but not on the “intermediate” level of CSS and browser implementation thereof.I believe last time I asked about it, which I think was about 6 months ago, you said something that I remembered as approximately that storing it clientside was the only available option for reasons I don’t remember, and that the cost that sometimes the browser forgets clientside settings is just one that dark mode users will have to bear. that takeaway was frustrating and has left me wanting to push about this. it’s entirely possible I misremembered.
The setting is saved by a cookie, which is the same way we store your login token information. I.e. if someone loses their theme cookie, they very likely would also be logged out, so we really can’t do better than that kind of setting (we could make it so that we automatically restore your preference when you log in again, but that seems like it doesn’t really change the basic experience).
I found at least one repro: set dark mode, edit your user settings, tada light mode. I thought I remembered it resetting to light mode without logging me out or a user setting edit, though. I could believe it’s not the storing-it-clientside that’s causing the resets. I haven’t seen as many for a few months, not sure why.
incidentally, you might find https://bottosson.github.io/misc/colorpicker/ to be a useful tool
Ah, that is definitely a bug and we should fix it. I’ll add it to the list.
My preference, by default, is something I communicate through the browser because the browser forwards on my light/dark preferences to websites.
In general, I want websites to do whatever my OS is set to do by default.
This is what Macs do by near-default, but some people use dark mode on 24⁄7 and some people use light mode 24⁄7. It’s not what all browsers+OS setups do.
Yes, that is what I meant. At least Macs do this by default, to the frustration of a non-trivial fraction of users who are now half of the time presented with visual designs that are half-baked, inadequate and barely tested, because realistically maintaining both a dark mode and a light mode design for a website is very hard.
Human color and space perception doesn’t work symmetrically across light and dark contrasts, so a well-designed dark website and a well-designed light website just look very different from each other on many dimensions. You can of course do it with CSS, but we are not talking about just inverting all the colors, we are talking about at the very least hand-picking all the shades, and realistically substantially changing the layout, spacing and structure of your app (so e.g. you don’t end up with large grey areas in a dark mode setting, which stand out vastly more in dark mode than equally high-contrast grey sections in a light mode).
I recommend my
color-scheme-convert.phpto automatically convert entire style sheets to a dark color scheme and perform the requisite gamma adjustment. (Which is to say, this script is specifically designed to solve the “Human color and space perception doesn’t work symmetrically across light and dark contrasts” problem.)It’s what we use to auto-generate the dark mode styles for
gwern.net, and is also used for the same purpose in PmWiki.(Some additional hand-adjustments may be necessary for some elements. However, the script dramatically reduces the workload of doing the conversion, and allows the great majority of it to be automated.)
FWIW, my impression is that while the gwern.net dark mode was a ton of work to create, due to requiring a total refactoring of the CSS and deal with the flash-of-white issue and figure out the correct three-mode behavior, and create tooling like the color conversion script or needing to create InvertOrNot.com for acceptable images, or tweak the syntax highlighting colors to look right in dark-mode… But once we finished paying all of that, the maintenance burden has been relatively small. I have to patch up the occasional image not inverting right and we have to occasionally special case some Wikipedia popups CSS, but it’s on net less effort than much of the website (eg. Apple device support, or the local archive system, are perennial hassles).
The gwernnet dark-mode is pretty good engineering work overall. We should’ve done a design-graveyard writeup to explain not just how it works (non-obvious) but the problems with the more obvious approaches and what problems we had etc. I fear it might be too late to write it now even if we had the time...
I think Gwern.net lends itself somewhat more to the maintenance burden being small. As one example, LessWrong for much of its UI leverages half-transparent images that fade to a white background. Making them be harmonious for dark mode basically means making two images each time.
For example, see this Sequences Spotlight in dark mode:
The image borders are exposed, and the white fade does not work. Compare to the fully functional light mode:
For most things like this we have a pass that tries to edit the images to properly work in both light and dark mode, but it requires a decent amount of artistic judgement each time.
To be honest, I don’t like the light-mode example either. I think it’s bad to have your text visibly overlapping like that. (If I made an image which I had put
.float-right .outline-noton to get the same effect on gwernnet and I saw your ‘good’ white-mode version, I would be immediately complaining to Obormot about his CSS being busted.) So in this example, isn’t a lot of the problem that the UI elements are overlapping so the text is spilling over onto the scales and blocking the wires etc, and the dark-mode merely exacerbates the problem and fixing the core problem would also fix the dark-mode issue?Nah, the problem isn’t the UI elements overlapping the text. I just happened to choose an image that also had other issues. You would still end up with an ugly fade and a harsh transition unless someone noticed in time and uploaded a new image, even if the image was more properly placed on the right edge of the spotlight item (and separately, I think the image overlapping a bit with the text is basically fine and I consider it less of an issue, but that seems orthogonal to the point).
I’m hoping the negative agreement karma for the parent comment isn’t for this — it’s just for “maintaining both a dark mode and a light mode design for a website is very hard” (emphasis added, as distinct from creation).
The above blockquote makes me want to say to the studio audience “Why are you booing — he’s right!”.