Support website's native dark mode

[rugk]

Firefox 67 introduced the new prefers-color-scheme CSS media feature. (It's not currently available for any other browsers that support browser/WebExtensions.)

With that websites can detect a dark system mode and adjust their design.

It would obviously be great, if you could integrate that, somehow. And there are many possibilities.

---

That said, I've already tried that (to force a particular design) and it is really not a nice thing to implement. At least forcing the black design works, as this is how websites likely implement it, but anything else is likely not really possible…

So this is rather a proof-of-concept (although it works quite fine if you just want to force the websites to use their native black design.).

Test the add-on here!

Source code: https://github.com/rugk/website-dark-mode-switcher/

What is easy is:

• get the system state and apply the add-on based on it. (just a .matchMedia query and you know it)

What is hard is:

• forcing websites to use a particular design

You may also just disable this add-on on sites, where you detect it used. It opens many possibilities/ideas…

Edit: Due to new Firefox APIs the v2 of the linked extension is much more powerful and now can easily and reliably force the dark or light mode on websites.

---

Test sites are linked in the add-on, but here again:

• https://webkit.org/blog/
• https://stuffandnonsense.co.uk/blog/redesigning-your-product-and-website-for-dark-mode

[rugk]

BTW, as the current way is quite hard, I asked Mozilla to implement an API or so for this feature: https://bugzilla.mozilla.org/show_bug.cgi?id=1547818

Please upvote, if you want this, too.

[awtrimpe]

Support for prefers-color-scheme will now be available in Chrome 76

https://blog.chromium.org/2019/06/chrome-76-beta-dark-mode-payments-new.html

[jacob-j]

Changing the media screen variable to screen and (prefers-color-scheme: dark) in the files src/inject/dynamic-theme/index.ts and src/inject/dynamic-theme/style-manager.ts would solve this for dynamic theme.

Only thing that is needed in the extension is sending a boolean, "automatic detection" variable from the extension so it isn't turned on by default.

I don't have time to work on this right now, but could take a look later on.

[FranklinYu]

If the functionality of Dark Website Forcer is incorporate into this extension, do we also need to add those websites to dark-sites.config?

Scratch that. I think we should add them to Global Dark List now regardless, since most operating systems already support them.

[FranklinYu]

Note that this isn't working yet on Linux for Chrome: https://crbug.com/998903

[sergeysova]

What about to add support for auto changing theme to dark or light for macOS Chrome?

[cnheider]

Would be cool with OS dark mode synchronisation as well, enabling/disabling dark reader based on system wide preferences. It is probably easily implemented by the proxy of "prefers-color-scheme", but at least Windows 10 (see AppsUseLightTheme, SystemUsesLightTheme) and a couple of linux desktops has flags for dark mode (see gtk-application-prefer-dark-theme...)

[Gusted]

@cnheider

https://darkreader.org/blog/automation/

[Gusted]

Removing in the title (prefers-color-scheme) as it has nothing to do with detecting a dark mode on a Site.

[flying-sheep]

You may also just disable this add-on on sites, where you detect it used. It opens many possibilities/ideas…

This is the part that I’m after. My personal page and I guess many other small pages support dark mode and will show ugly black rectangles when the addon is activated.

It would be nice to have a setting “Apply to sites that autoadapt themselves” where you could toggle between the current behavior (Forcing application on every site) vs trusting that websites with prefers-color-scheme queries will have a dark mode.

A bit tricky since there’s e.g. React sites that don’t have static CSS with that media query but instead a dynamic one: https://material-ui.com/components/use-media-query/ (all (hopefully) based on window.matchMedia)

[shroudedcode]

Edit: I totally missed that there's already a pull request for this. 🤦‍♂️

There's now two standard ways of doing this:

• The color-scheme CSS attribute (oftentimes set on :root)
• The color-scheme meta tag (which automatically sets that attribute on :root)

While they both technically mean something else ("please render default elements like inputs with [a particular color scheme]"), I think they can be reasonably understood to mean "this website natively supports [said color scheme]" in the vast majority of cases, so adding support for them would solve this problem for a lot of websites.

If anyone's interested in how color-scheme works, I can really recommend this web.dev article.

[flying-sheep]

Awesome! So once that’s merged and my page contains <meta name=color-scheme content="light dark">, both the browser and dark reader would know that my page supports a dark color scheme!

[Gusted]

Awesome! So once that’s merged and my page contains <meta name=color-scheme content="light dark">, both the browser and dark reader would know that my page supports a dark color scheme!

Yep. And if the user uses prefers a dark-color scheme we won't enable Dark Reader so it will uses the site's one. While when it's detected that the user prefers a light color scheme we will still enable Dark Reader as the site will not according to this colour-scheme documentation display their native dark mode.

Regards,
Gusted

[Mennaruuk]

Hi!! Are there any updates about this? I love Dark Reader!

[FranklinYu]

These sites use dynamic theme (i.e., detect theme while allowing override):

• https://material-ui.com (mentioned above)
• https://docs.docker.com

These sites use dynamic mode, but user session is required for switching themes:

• https://sourcegraph.com/search
• https://pastebin.com

[Gusted]

Meta tags could be so much more reliable

I'm going to repeat myself, they currently aren't that reliable.

"Metadata is error-prone, as long websites don't even know how to use it correctly, we shouldn't rely on it. It will cause more bad than good" - #1285 (comment)

but many websites take some time until they completely apply their dark mode.. a few seconds or so. Many websites don't work for me... Also it is annoying to see that on websites like github for example, when you reload, it first applies the dark mode and then removes it again... its just not nice.

That's how the current implementation work, we're waiting for Dark Reader to finish it's first rounds of modification which should give the browser + the site some time to do their thing and in most cases already load their dark mode(if they have any).

The behavior that you observe, that dark mode is still being applied is the technical limitation of detecting a site's dark mode. We can of course simple wait for the site to load to avoid that issue, but that's not how Dark Reader works. Nobody wants to see the site's original theme, it may in this case be a annoyance because the site is already dark themed, but for non-dark themed sites it will cause a huge white flash for your eyes.

[LasseRosenow]

as long websites don't even know how to use it correctly

I would be interested in why you are so sure about the fact that websites don't know how to implement the meta tag?

[Gusted]

I would be interested in why you are so sure about the fact that websites don't know how to implement the meta tag?

Because there seems to be a misunderstanding that the meta tag's functionality actually is. As per spec: https://html.spec.whatwg.org/multipage/semantics.html#meta-color-scheme It's simply a hint to the browser to style some things(like currently the scrollbar) dark-themed. While it may also serve(only defined in example, pretty vague) that the site implements a dark mode.

---

Btw, I'm not sure, it's just a vague thing that popped up in the HTML specifications and from my perspective hasn't a clear definition, if a big site(like google or reddit or youtube) start to only use it to say to the browser to style elements dark-themed(regardless the site's native color-scheme), the bugs about it will roll in, I have to decide if we should add a "denylist" for such sites(spoiler, I don't want more list than we currently have) or remove the feature again.

It's too vague and error-prone to even consider it as a option IMO.

[LasseRosenow]

I mean it does a bit more than just make the scrollbar dark. It also changes the background color and the text color of the site. In general just all default gui elements become dark including the default color scheme. (Because they use the default color scheme ...) So if you apply this meta tag, your whole website automatically becomes dark. Except you override those, then of course you could do funny things, but I would be confused about why anyone would do such a thing :D

In general I don't think that there are high risks of it being misused because whenever a site sets this meta tag to dark, it gets a lot of dark styled default behaviour, which is something that the site would not want if its not a dark site, or am I missing something?

[flying-sheep]

That’s exactly how it is. @Gusted please read the standard draft more carefully, it’s all there.

Il’ll use dark reader once it has a setting to reliably turn itself off on a website that claims it supports dark mode.

[Gusted]

I mean it does a bit more than just make the scrollbar dark. It also changes the background color and the text color of the site. In general just all default gui elements become dark including the default color scheme. (Because they use the default color scheme ...) So if you apply this meta tag, your whole website automatically becomes dark. Except you override those, then of course you could do funny things, but I would be confused about why anyone would do such a thing :D

That's correct, well, why would anyone not use the CSS to make your site nicer? I don't know of any single site that doesn't use CSS and let the browser decide which colors the site will use. The implementations I've seen so far, has been to get dark-styles elements(scrollbar, dropdowns, inputs etc.), we're actually abusing that fact ourselves: #8012 to get those elements dark-themed. Yet it doesn't imply that the site itself is dark, it can still override to use a light themed background color.

In general I don't think that there are high risks of it being misused because whenever a site sets this meta tag to dark, it gets a lot of dark styled default behaviour, which is something that the site would not want if its not a dark site, or am I missing something?

I'm not sure about the risks, a site simply can still set other values then it's supposed to have(according to the color-scheme), it still sounds error-prone in my ears.

The elements indeed gets dark-styles default behavior, but from my own experience web developers are using it to style the native elements control but still decide most other colors(html, body etc.) which can still be light. A site's implementation can be "wrong" very easily.

Il’ll use dark reader once it has a setting to reliably turn itself off on a website that claims it supports dark mode.

We're currently already doing that, see #7995, currently we're detecting it, as not every dark site will actually use meta tags.

---

On another note, I'm not actually quite sure why we still should support/detect the meta tag, the detection(#7995) should catch most of those site. Supporting the meta tag as well, will only increase small amount of sites and can be dangerous if the meta tag + site's CSS is "incorrect". Unless there's a sudden movement among sites to include such meta tag, I personally think it's not worth the hassle of checking for it.

[flying-sheep]

We're currently already doing that, see #7995, currently we're detecting it, as not every dark site will actually use meta tags.

Exactly. I don’t want the detection code to run when there’s a metadata tag. I want a setting to trust it.

[LasseRosenow]

we're actually abusing that fact ourselves: #8012 to get those elements dark-themed.

I would not consider it to be an abusement to set the tag, if the rest of the site is dark. It is correct to activate the tag when a site is dark. Even if it got dark through an extension. The only thing that matters is the current state.

I'm not sure about the risks, a site simply can still set other values then it's supposed to have(according to the color-scheme), it still sounds error-prone in my ears.

You keep saying that and I will keep saying that I just can't believe it to be that much of a risk as you give it credit to be. Just because it "is possible" that does not automatically mean, that people will so it, of it makes no sense at all. And activating dark styles for a website that is not dark just seems extremely weird and I just don't think people are actually doing that.

On another note, I'm not actually quite sure why we still should support/detect the meta tag, the detection(#7995) should catch most of those site.

As said before, the meta tag would help very much on deciding if a site should be converted to dark mode or not "early on" this would prevent those weird rendering annoyances where the side gets first converted and then unconverted, as dark reader detects that it actually already has a dark mode.

Also there are still many sites that don't work with dark reader. For example I use a CMS called directus all the time and dark reader just doesn't get its in dark mode. But the meta tag would work just fine.

---

In general I think those decisions should not be made on a "feeling", that stuff might be misused. Maybe we should just collect some data on pages that use those tags and if they implement dark mode or not. This would give us an actual answer to the big question if this thing really actually gets misused or not. What do you think?

[Gusted]

Exactly. I don’t want the detection code to run when there’s a metadata tag. I want a setting to trust it.

Seems like a reasonable argument to add it.

Also there are still many sites that don't work with dark reader. For example I use a CMS called directus all the time and dark reader just doesn't get its in dark mode. But the meta tag would work just fine.

This doesn't seems like related to detecting a dark mode?

In general I think those decisions should not be made on a "feeling", that stuff might be misused. Maybe we should just collect some data on pages that use those tags and if they implement dark mode or not. This would give us an actual answer to the big question if this thing really actually gets misused or not. What do you think?

Yeah, I'm not that big on data collection so that's a big no-go. I can add a secret setting somewhere in the UI so average users won't suddenly spam with bug reports why dark reader doesn't work anymore(because the risk is still there, how big it may be), because in the past adding new features which are experimental only resulted in negative things and ultimately being removed. I'm trying to prevent such new scenario's again, by only carefully adding new features which are stable for the 99.99% use-case. I will update #3902 soon to include it.

[Gusted]

While we're at the topic:

Let's take github.com, it has the <meta name="color-scheme" content="light dark"> meta tag. So that means it will apply accordingly to your preferred color scheme. Dark Reader now knows, the dark mode doesn't need to be applied, because the user's preferred color scheme is dark, so github.com will theme it!

Now, this is the first time that this user actually visits github.com and decide that their color-scheme isn't that great, so it goes to github's settings and set it white, now Dark Reader hasn't a clue that the light theme is enabled and won't do anything.

How would Dark Reader handle such case? Making the user again explicitly enable github.com in the popup is annoyance IMO and should be avoided and can be considered a bug by the user.

[flying-sheep]

Respect the user’s choice to explicitly choose a light theme for GitHub only.

[Gusted]

I personally would've expect that Dark Reader would've taken over dark theme styling(even if a refresh is needed to kick the detection).

[axkibe]

Can't we just scan a sites CSS and if it has any prefers-color-scheme query in it assume it respects native dark mode built in and auto-disable darkreader for it? (these are those where it usually inverts it again, creating a white background again) (And assuming it checks if prefers-color-scheme is turned on by user)

Oh and Chrome on Linux has a workaround, change the Exec line your chrome.desktopfile to
Exec=/usr/bin/google-chrome-stable --force-dark-mode %U

It's "just" missing the UI to conveniently turn it on/off like on Windows or like Firefox.

[Gusted]

Can't we just scan a sites CSS and if it has any prefers-color-scheme query in it assume it respects native dark mode built in and auto-disable darkreader for it? (these are those where it usually inverts it again, creating a white background again) (And assuming it checks if prefers-color-scheme is turned on by user)

I've tried a while ago(1.5+ years) and some major sites are quite misbehaving. Well, it's a good heuristic, it's unfortunately not a rock solid condition to check for.

[alexanderby]

The feature was added some time ago via #7995, you need to activate it in the UI. The algorithm is improved from time to time. If you see the issues please leave a brief message with a link.

[StigNygaard]

The algorithm is improved from time to time. If you see the issues please leave a brief message with a link

Doesn't detect "native darkmode" at first on https://www.rockland.dk/.
Reload or navigation on the site activates the "native darkmode".

[532910]

rockland.dk

just tested: works fine for me from the first vist

[StigNygaard]

rockland.dk
just tested: works fine for me from the first vist

Hmm, okay. Maybe I can't find out defining the right settings. I find them a bit confusing. Thanks for the check, I will try playing around with settings a bit more.
(If it makes any difference, I' using Firefox on Win11)

[flying-sheep]

Why does that PR do some weird CSS calculation?

All you have to do to check if a website officially supports dark mode is

const colorSchemes = document.querySelector("meta[name='color-scheme']").getAttribute("content")
const supportsDarkMode = colorSchemes.split(/\s+/).includes("dark")

The mentioned website https://www.rockland.dk/ defines

<meta name="color-scheme" content="light dark">

there should be zero configuration or question necessary before dark reader sees that and turns itself off immediately.

[alexanderby]

The suggestion is good and it can improve the detection. Unfortunately this meta tag is rarely used and there is still the need to check the actual colours used on the website.

[alexanderby]

Please submit the websites where it doesn't work correctly here, as it was the earliest feature suggestion of that type #81

[532910]

Oh, sorry, I was wrong: darkreader ignores rockland.dk's dark theme, even after page reload. Enable-disable darkreader makes it work right.

[alexanderby]

@532910 That's alright, the meta fix works well. However I blocked Mr Philipp A. from participation in this conversation for his toxic tone.

Unfortunately the previous releases are still under review for Chrome and Firefox, so I will publish this fix as soon as it passes, and we will see how it goes.

[ewtoombs]

The feature was added some time ago via #7995, you need to activate it in the UI. The algorithm is improved from time to time. If you see the issues please leave a brief message with a link.

I really really think this should be on by default.