Toggle styles according to prefers-color-scheme

[kristofferR]

As you might know, the newly released macOS Mojave has a great Dark Mode implementation where all supported apps automatically change color theme to Dark when Dark Mode is toggled.

It would be great if Stylus could be compatible with Dark Mode and automatically be toggled based on the Dark Mode status.

[eight04]

It seems that it is doable: https://paulmillr.com/posts/using-dark-mode-in-css/.

Tickets for Firefox and Chrome:
https://bugzilla.mozilla.org/show_bug.cgi?id=1494034
https://crbug.com/889087

We need a dark theme first. And it should be toggleable or at least be able to override the default theme. I think this can be implemented in two ways:

1. Rewrite our CSS and refactor them into two parts. One defines the layout and the other defines the skin. Therefore, we can switch from something like light-theme.css to dark-theme.css to apply different styles when the dark mode is enabled.
2. Extract all colors/background to CSS variables. To enable the dark mode we can simply override these CSS variables. We don't have to rewrite all CSS in this way.

@narcolepticinsomniac might be interested to this feature.

[narcolepticinsomniac]

Extract all colors/background to CSS variables.

I've already pretty much done that in the UI PR. Still need to get the color-picker CSS file, but like 99% of colors are converted to variables.

We've always talked about having a UI color slider, which would be pretty cool. For that to even be a possibility, we needed to convert all colors to variables, so I did. They'll be useful anyway, regardless.

IDK how difficult a color slider will be to implement, but it's not exactly a high priority, so who knows when somebody will decide to work on it. Probably a while, so in the meantime, with all colors converted to variables, it'd be pretty easy to add simple color changing themes with minimal code. That bit of atomic CSS might come in handy as well, which is kinda what I had in mind when adding it, but never really followed through on.

Most of us agree that a light gray, lower contrast default would be preferable to the current high contrast, but some will prefer high contrast. All the other UI prefs are reversible, so that should most likely be too. We could probably implement 1 high contrast light (like the current default), 1 lower contrast light (new default), 1 high contrast dark, and 1 lower contrast dark fairly easily.

macOS Dark Mode is a simple query once you have a built-in theme.

[kristofferR]

Just to clarify, sorry for being unclear - I meant a way where either individual userstyles (preferable) or Stylus as a whole can be configured to be automatically enabled/disabled based on Dark Mode status.

That way users can get dark web pages at night/when Dark Mode is enabled, and light web pages when it's disabled. By using Stylus and dark userstyles, in combination with Dark Reader (for the rest of the web, without tailored userstyles), users would be able to get a perfect dark web automatically every night, and a light web during the day.

Having the UI of Stylus change color theme based on the Dark Mode setting would be awesome too of course.

[narcolepticinsomniac]

There's a PR for that which didn't garner enough interest, or get enough testing for the dev who worked on it at the time to finish.

We haven't abandoned the idea entirely, but it's definitely been back-burnered. If someone ever revives it, I would think it'd be preferable for such a feature to be a standalone, and not dependent on any OS specific queries.

[kristofferR]

Windows 10 got a dark mode toggle recently too, and hopefully the various Linux distros/desktop environments won't be too far behind (I know Gnome already has a Dark Mode toggle), so it's not just a macOS specific feature.

Dark Mode is huge trend, much more so now than when the #51 was active, and with the upcoming CSS query prefers-color-scheme, it will become even more important.

I can only speak for myself, but at least I didn't care much about dark web pages until the macOS Mojave Dark Mode implementation made light web pages such jarring shocks at night, as the gif in
this article nicely illustrates. I don't think I'm the only one who just recently started caring.

I think #62 (comment), has some good ideas, with

1. A setting for each style, whether it applies during nighttime, daytime, or both.
2. Depiction of this setting on the management page, as an icon.

Basing it on the system dark mode setting would likely be both easier to implement and simpler for the end users than cumbersome time/sunset based settings too.

Hopefully the focus on this feature can be reevaluated, as it's much more important than it used to be.

[narcolepticinsomniac]

Could be longer than you'd like to believe before the query gets cross-browser support. From one article: "This will very likely be mirrored in Chrome/Firefox within the year". Once it does, yeah it might be nice, but you're getting a little ahead of the slow process of progress.

[kristofferR]

Sure, but Stylus should be ready for the first browser that implements it, not the last browser. Dark Reader already has auto-toggling based on the system dark mode setting in the Safari version (and will likely get support for Firefox/Chrome quickly after they add the support), there's no reason for Stylus to lag behind.

[narcolepticinsomniac]

Dark Reader already has auto-toggling based on the system dark mode setting in the Safari version

We don't support Safari.

...and will likely get support for Firefox/Chrome quickly after they add the support

It's a solid idea. Good chance we will too, if and when it actually happens.

there's no reason for Stylus to lag behind

Lag behind what though? We should start working on a feature which depends on potential functionality that hasn't even been confirmed yet? If "probably within the year" is the best you have to go on, then you have nothing to go on. Sometimes these kinda things get fast-tracked, sometimes they drag on forever.

Chromium tends to be the determining factor, because they're the biggest player. If they implement it, FF will likely follow suit pretty quickly. When it lands in Canary or Nightly, there'll still be months before it makes it to stable, so that's when it'll make sense to start working on it. Remind us when that happens.

[huzecong]

Hi, now that Chrome 73 officially supports dark mode, would it be possible to move forward with this issue?

[kristofferR]

Chrome doesn't support it fully yet (it will in Chrome 75), Firefox supports it (in Firefox 67):

https://bugs.chromium.org/p/chromium/issues/detail?id=889087
https://bugzilla.mozilla.org/show_bug.cgi?id=1494034

There's more info here: darkreader/darkreader#745 (comment)

[xt0rted]

Support for this was just brought up in StylishThemes/GitHub-Dark#960. The Safari extension Cascadea already supports this per style based on the browser's setting (or a user override). An example of the UI can be seen in StylishThemes/GitHub-Dark#808 (comment).

[narcolepticinsomniac]

They're simple media queries, so they could be added as a usercss option, or USO advanced setting fairly easily, correct? I guess you guys are looking for some kinda solution that is automatically available for all styles on an individual basis?

I never understood the urge to ever prefer light styles, but that's just a matter of personal preference. I'm also not a MacOS or Win 10 user, and don't ever plan to be, so I'm not the target demo here in any respect. If anyone thinks such a feature is worth implementing, it's fine by me. Not something that should be enabled by default IMO, but otherwise, knock yourselves out.

Edit: Any feature like this would also need to check browser versions, and only present the setting if it's supported.

[Mottie]

they could be added as a usercss option

It's not that simple. As posted in GitHub Dark, the user wants the light theme to be visible during the day and the dark theme at night.

Also, wrapping a style in an @media would fail if the browser doesn't support it. So, we'd have to dynamically wrap the style according to the user setting (as @silverwind suggests):

• Always apply (no media wrap, default)
• Apply when in dark mode (wrap with dark-mode media)
• Apply when in light mode (wrap with light-mode media)

[narcolepticinsomniac]

Seems to me that if you wanted to make it work, you could, but maybe I'm missing the bigger picture. The more I think about it, the more I realize that I don't care enough about this to contemplate the details, let alone argue them.

I only really responded here in case anyone wanted confirmation they wouldn't get any argument from me about this kinda feature before they bother working on it. If it's something you wanna do, go for it.

[eight04]

Does prefers-color-scheme change according to time (light in the day and dark in the night)? If it does, this issue may close #51. Otherwise, we may have to implement an option like:

Toggle night mode according to:
[ ] Browser setting.
[ ] Time: [00:00] ~ [00:00]

Implementation details:

1. To mark some styles as prefer dark, we have to add a field preferDark: Boolean | void to the style. This can be extracted from usercss header or configured by users. (if style.preferDark == null then use style.usercssMeta.preferDark)
2. To detect changes to prefers-color-scheme media query, we have to test if MediaQueryList works in the background page.

[auscompgeek]

Does prefers-color-scheme change according to time (light in the day and dark in the night)?

I would presume something like that would be implemented at the OS level (which prefers-color-scheme is generally intended to follow). I have a suspicion that macOS and Windows already do this, although I might be wrong.

[kristofferR]

Does prefers-color-scheme change according to time (light in the day and dark in the night)?

I would presume something like that would be implemented at the OS level (which prefers-color-scheme is generally intended to follow). I have a suspicion that macOS and Windows already do this, although I might be wrong.

Yeah, it's handled by the OS (or third party apps like NightOwl).

[eight04]

Otherwise, we may have to implement an option like:

Toggle night mode according to:
[ ] Browser setting.
[ ] Time: [00:00] ~ [00:00]

I think we also need a "never" option for users who don't want to toggle styles according to night mode:

Toggle styles according to night mode:
[ ] Never
[ ] By browser setting
[ ] By time [00:00] ~ [00:00]

Default is "Never", which is the current behavior. Should we use the second option as the default? It could be confusing that a user finds that a style is not applied after installed.

For per-style setting, users can choose the preferred type:

The style should be applied:
[ ] Always
[ ] In the day
[ ] In the night

Default is "Always".

Should we allow style authors to choose a default value in usercss? Suppose night is chosen, isn't it confusing for users who use the browser with a light theme?

[Mottie]

I'm starting to think if we add a time (day/night mode) it may interfere with the OS's setting. If we do add it, instead of using "In the day" and "In the night", we should have a time because the user may not always want the change to occur at sunrise or sunset.

Also, it will be confusing to the user as to why a style isn't being applied unless we add some indicator showing that it is disabled, excluded and/or off because of the mode.

[kristofferR]

The words night/day shouldn't be used at all - it would just be confusing as you can easily switch OS color scheme whenever you want. Some people might even use dark mode during the day and light mode during the the night. Dark/Light Mode is the proper terms.

[eight04]

The words night/day shouldn't be used at all - it would just be confusing as you can easily switch OS color scheme whenever you want. Some people might even use dark mode during the day and light mode during the the night. Dark/Light Mode is the proper terms.

Like this?
global setting

Toggle styles according to light/dark mode:
[ ] Never
[ ] By browser setting
[ ] By night time [00:00] ~ [00:00]
// or with a day option?
[ ] By time
    Day: [00:00] ~ [00:00]
    Night: [00:00] ~ [00:00]

per style setting

The style should be applied:
[ ] Always
[ ] In light mode
[ ] In dark mode

[kristofferR]

Pretty much, but I would also change "browser setting" to "system preference", as it's a global system setting. I think "automatically" is also more logical than "according to light/dark mode", since that would be confusing if the time option was chosen and the system Dark Mode setting was ignored.

Most sources also capitalize Light/Dark Mode when it is controlled by the OS. I think that would be beneficial for Stylus too, as it would help users distinguish between functionality internal to just the extension and functionality integrated with the OS preference.

Here's the way I think would be best:

global setting

Toggle styles automatically:
[ ] Never
[ ] By system preference
[ ] By night time [00:00] ~ [00:00]
// or with a day option?
[ ] By time
    Day: [00:00] ~ [00:00]
    Night: [00:00] ~ [00:00]

per style setting

The style should be applied:
[ ] Always
[ ] In Light Mode
[ ] In Dark Mode

[jonaskuske]

Just for reference, personally I use this little Windows 10 app to automatically enable and disable dark mode in the system preferences depending on sunrise and sunset: https://github.com/Armin2208/Windows-Auto-Night-Mode
And yep, that's a system-wide (global) setting, affecting the UI of Windows itself, all apps including web browsers, and websites as long as they use the media query that is mentioned here. (or the even never color-scheme property which allows the browser to adjust its default user agent styles according to the active color scheme)

[eight04]

You may want to test this branch: #736

[elsiehupp]

I can't tell if this issue is primarily about toggling web styles or about toggling the style of the interface of Stylus itself. For Stylus itself, I imagine something very simple, like the following, would do the trick:

@media (prefers-color-scheme: dark) {
    /* Invert invert lightness but not hue */
    html {
        filter: invert(100%) hue-rotate(180deg);
    }

    /* Set explicit background color (necessary for Firefox) */
    html {
        background-color: #111;
    }

    /* Revert the invert where necessary */
    .foobar {
        filter: invert(100%) hue-rotate(180deg);
    }

    /* Revert the revert for child elements where necessary */
    .foobar barfoo {
        filter: invert(100%) hue-rotate(180deg);
    }
}

The only instance where I imagine it would be absolutely necessary to revert the global invert is with color swatches, though sometimes it's nice to fix button gradients so they don't look upside-down.

Here's a screenshot of filter: invert(100%) hue-rotate(180deg); and background-color: #111; applied to the html element via the Firefox web inspector:

(Note the inverted color swatch.)

Thoughts? As with most implementations for @media (prefers-color-scheme: dark), I imagine most of the work would be creating a custom opt-out button, rather than implementing the CSS itself.

Also, if possible, it might be nice to pull some of the colors from the browser user interface, since, for example, on Firefox on Big Sur, the Firefox UI in Dark Mode has a slightly color cast to it that the plugin UI does not.