Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dark mode #188

wants to merge 4 commits into
base: develop


Copy link

commented Oct 2, 2019

This adds dark mode css to writefreely which gets enabled automatically when the OS is set to dark mode (prefers-color-scheme: dark media query). It also leverages the built in pad dark mode functionality to choose the dark pad by default if prefers-color-scheme is dark.

That is all. I tried to just invert the colors and not do any other stylistic choices.

Michael Demetriou and others added 4 commits Jun 25, 2019
in OS preferences. I will be using it myself and fix things until
I find out that this is adequate to merge to develop.
This just queries the browser whether `prefers-color-scheme` is set
and chooses dark mode if needed, and only if the user hasn't manually
set a scheme by pushing the button.
`prefers-dark-mode` header. I think I have covered all the bases.

This comment has been minimized.

Copy link

commented Oct 4, 2019

confirmed working: firefox 69.0.1
not working: chromium 76.0.3809.132, palemoon 28.7.1
tested with qutebrowser but the backend is only chromium 73 so won't support it as it was added in 76.

it looks like there are issue with chromium/chrome on linux using gtk themes that are still being ironed out, so it will work eventually. see


This comment has been minimized.

Copy link

commented Oct 9, 2019

Thanks for taking the time to explore this, @qwazix! I like the idea in theory, but I'm still thinking about if this should be in the core platform. Just some thoughts below.

I do like the idea of the system setting the default mode of the pad -- I think that's a great use case for dark mode that we could incorporate today. But I'm very hesitant to change the entire site (especially the reading experience) to respect the mode. A few reasons:

  • Users might not want dark mode affecting their system this deeply. I'm not sure about how widespread this feeling is, but it's my personal intuition.

  • Readability is worse with light text on a dark background and can cause more eye strain, especially when reading in light conditions (this article goes into some of the details). As a platform made to enhance the reading experience as much as possible, I think this would go against our core design philosophy.

  • This makes customizing blogs with CSS more difficult, since users would need to code against both dark and light mode. For example, even if I only wanted to create a light theme, I'd still need to put in the right CSS to disable our default dark mode rendering.

  • Since it's tied to the system settings, if a user doesn't like reading in dark mode, there's nothing they can do besides turn off the setting for their entire system, which isn't a very good user experience. This is probably part of my intuition mentioned in the first point.

Considering all of this (and barring any other input), I think we should keep the part where the system setting determines the initial Pad theme, and then separately publish your CSS in our external resources. That way, instance admins and blog users can include it if they want their WF instance or blog to support dark mode.


This comment has been minimized.

Copy link

commented Oct 10, 2019

Ok perfect I will separate the changes into two branches.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
3 participants
You can’t perform that action at this time.