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!”.
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!”.