I don’t know how considered this is, but, we’ve up a lot of the site aesthetic built around the light mode (aiming for a “watercolor on paper” vibe) and it is fairly hard to get it to work well on dark mode as well.
Honestly. I am often a “dark mode” preference person, but I use lesswrong in light mode, because I think lesswrong has a light mode aesthetic and looks very good in it. I personally don’t like the dark mode very much. I think it is perfectly acceptable to have light mode by default. I think that serving dark mode to users that have their system theme set to dark mode is not necessarily good. It costs you just a few seconds to change it if you don’t like it, and showing the site’s identity and aesthetic is good for newcomers. This is just my anecdotal experience, but it is at least evidence that not all dark system theme people prefer to have automatic dark mode.
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!”.
FWIW, I don’t think the site looks significantly worse on dark mode, although I can understand the desire not to have to optimize for two colorschemes.
I think the baseline site is pretty fine in darkmode, it’s just that whenever we do artsy illustration stuff it’s only really as-an-afterthought ported to darkmode. So, I think we have at least some preference for people’s first experience of it to be on lightmode so that you at least for-a-bit get a sense of what the aesthetic is meant to be.
(the part where it keeps reverting whenever you lose localstorage does sound annoying, sorry about that)
So, I think we have at least some preference for people’s first experience of it to be on lightmode so that you at least for-a-bit get a sense of what the aesthetic is meant to be.
This makes sense in a vacuum, but…
…if someone’s first visit to Less Wrong is in the evening after the sun goes down, then his first impression of the site will be colored by an unpleasantly bright website that doesn’t work properly in dark mode. Is that really what you want?
I’ve designed sites where the light mode has a nice background flourish, but I never figured out how to make it work nicely in dark mode.
So I just had a solid dark color in dark mode (instead of the background image) and left the image as a light-mode-only thing, which makes it something like an easter egg if one usually browses the site with a dark-mode preference being forwarded on to the site.
This kind of thing happens to me, as well — I have wallpaper that changes with the time of day, and I generally don’t see the sunrise versions of the wallpaper unless I’m at my computer crazy early or crazy late.
I definitely do not stand by this as either explicit Lightcone policy or my own considered opinion, but, I feel like a bunch of forces on the internet nudge everyone towards the same generic site designs (mobile-first, darkmode ready, etc), and while I agree there is a cost, I do feel actively sad about the tradeoff in the other direction.
(like, there are a lot of websites that don’t have a proper darkmode. And I… just… turn down the brightness if it’s a big deal, which it usually isn’t? I don’t really like most websites turning dark at night. And again, if you set the setting once on LessWrong it mostly should be stable, I don’t really buy that there are that many people who get the setting lost?)
I feel like a bunch of forces on the internet nudge everyone towards the same generic site designs […], and while I agree there is a cost, I do feel actively sad about the tradeoff in the other direction.
Mobile-first cuts out a lot of room for self-expression, agreed.
Dark mode, meanwhile, I like too much. Heck, I have a site where one might reasonably ask “where’s the light mode?”.
And again, if you set the setting once on LessWrong it mostly should be stable, I don’t really buy that there are that many people who get the setting lost?
Safari is set to throw out a site’s cookies if it isn’t visited in seven days. I don’t know about other browsers.
I don’t know how considered this is, but, we’ve up a lot of the site aesthetic built around the light mode (aiming for a “watercolor on paper” vibe) and it is fairly hard to get it to work well on dark mode as well.
that’s not worth being blinding for someone who’s indicated a preference for dark mode
Honestly. I am often a “dark mode” preference person, but I use lesswrong in light mode, because I think lesswrong has a light mode aesthetic and looks very good in it. I personally don’t like the dark mode very much. I think it is perfectly acceptable to have light mode by default. I think that serving dark mode to users that have their system theme set to dark mode is not necessarily good. It costs you just a few seconds to change it if you don’t like it, and showing the site’s identity and aesthetic is good for newcomers. This is just my anecdotal experience, but it is at least evidence that not all dark system theme people prefer to have automatic dark mode.
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!”.
FWIW, I don’t think the site looks significantly worse on dark mode, although I can understand the desire not to have to optimize for two colorschemes.
I think the baseline site is pretty fine in darkmode, it’s just that whenever we do artsy illustration stuff it’s only really as-an-afterthought ported to darkmode. So, I think we have at least some preference for people’s first experience of it to be on lightmode so that you at least for-a-bit get a sense of what the aesthetic is meant to be.
(the part where it keeps reverting whenever you lose localstorage does sound annoying, sorry about that)
This makes sense in a vacuum, but…
…if someone’s first visit to Less Wrong is in the evening after the sun goes down, then his first impression of the site will be colored by an unpleasantly bright website that doesn’t work properly in dark mode. Is that really what you want?
I’ve designed sites where the light mode has a nice background flourish, but I never figured out how to make it work nicely in dark mode.
So I just had a solid dark color in dark mode (instead of the background image) and left the image as a light-mode-only thing, which makes it something like an easter egg if one usually browses the site with a dark-mode preference being forwarded on to the site.
This kind of thing happens to me, as well — I have wallpaper that changes with the time of day, and I generally don’t see the sunrise versions of the wallpaper unless I’m at my computer crazy early or crazy late.
I definitely do not stand by this as either explicit Lightcone policy or my own considered opinion, but, I feel like a bunch of forces on the internet nudge everyone towards the same generic site designs (mobile-first, darkmode ready, etc), and while I agree there is a cost, I do feel actively sad about the tradeoff in the other direction.
(like, there are a lot of websites that don’t have a proper darkmode. And I… just… turn down the brightness if it’s a big deal, which it usually isn’t? I don’t really like most websites turning dark at night. And again, if you set the setting once on LessWrong it mostly should be stable, I don’t really buy that there are that many people who get the setting lost?)
Mobile-first cuts out a lot of room for self-expression, agreed.
Dark mode, meanwhile, I like too much. Heck, I have a site where one might reasonably ask “where’s the light mode?”.
Safari is set to throw out a site’s cookies if it isn’t visited in seven days. I don’t know about other browsers.
I think LW’s dark mode is bad, and is actually too dark. Almost nobody uses full #000000 for dark mode.