What is the current status on this? Adding official dark mode to Wikipedia is long overdue.

@Mrconter1: Welcome to Phabricator. Please read all of the previous comments first, e.g. T26070#7670546. Thanks.

Hi there! I just joined as I was curious why Wikipedia did not have a Dark Mode.
As far as I can see, this is an installable extension, but not an integrated feature in the site (like a top bar toogle button), is that something you do have on mind to make available in the future?
If so I would lilke to be part of the development of that!

@Migerusantte our main concerns are not with building dark mode, but sustainably maintaining it. Right now there is a lot of technical debt relating to skins we need to take care of before adding dark mode. I think in future the hope is that skins use CSS/LESS variables for their themes and these can easily be tweaked for a dark mode. There are lots of small tasks relating to pushing in that direction that @Volker_E might be able to point to you if you are interested in helping us work towards developing one.

@Migerusantte Hi, myself and a few of my peers (as in Wikimedia Design team members) have come up with an exploration following several design guidelines and agreements in https://en.wikipedia.org/wiki/User:Volker_E._(WMF)/dark-mode – it's available as gadget in your preferences in English Wikipedia.
It would be great if you try it and provide feedback on the corresponding talk page.

Two related issues:

First, I trust any skins will meet colourblindness accessibility guidelines

Second, if one uses software like Redshift on the default skin colours, the blue links eventually become indistinguishable from the black text. It'd be nice if dark modes worked on a monitor set to render redscale. This would also meet the astronomy usecase detailed by @C933103.

These two issues overlap. Making the skin work in redscale would be isomorphic to making it work in greyscale, which makes it accessible to people with all types of colourblindness. No additional maintenance overhead.

I've tested the gadget with Redshift.

Suggested implementation steps for when we want to go ahead with this:

1. Copy @Volker_E and friend's gadget code into core dropping any styles relating to extensions/skins/templates (https://gerrit.wikimedia.org/r/c/mediawiki/core/+/857836)
2. Enable it in desired skin (preferably behind opt in feature flag) https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/857837
3. Add extension/template specific rules to the extension/template itself as @media screen and ( prefers-color-scheme: dark ) {

I see 3 as the main bulk of the work here, so if anyone does want to move this along, helping that happen seems like the best use of time.

I've created a patchdemo of what the generic bits look like at https://patchdemo.wmflabs.org/wikis/3343e615d8/wiki/Spain?useskin=vector-2022 - I take no credit for the code or work here - Volker has very much been the driver of this work - just wanted to throw this up so we can compare and contrast against the more complete gadget.

I don't know if it should be a blocker or not but the dark mode being used in mobile frontend leads to scary pictures in search:

(it might not be a blocker as mobile is a different skin altogether?)

In T26070#8401685, @Ladsgroup wrote:

I don't know if it should be a blocker or not but the dark mode being used in mobile frontend leads to scary pictures in search:

(it might not be a blocker as mobile is a different skin altogether?)

The solution here is to either add the classes used by the widget to the non-inversion selector, or to add the standard mw-no-invert class to the images.

The latter is a much better way to do this. Darkmode should not have to maintain a list of CSS classes by every extension that uses background images.

Filed as T345281

Do we really need years to modify a simple CSS? I wonder what the priorities are. Or are you guys applying the bad practice of if something works, don't touch it?

In T26070#9131701, @Esanders wrote:

In T26070#8401685, @Ladsgroup wrote:

I don't know if it should be a blocker or not but the dark mode being used in mobile frontend leads to scary pictures in search:

(it might not be a blocker as mobile is a different skin altogether?)

The solution here is to either add the classes used by the widget to the non-inversion selector, or to add the standard mw-no-invert class to the images.

The latter is a much better way to do this. Darkmode should not have to maintain a list of CSS classes by every extension that uses background images.

Just invert image colors for png/svg/icons and not for jpeg our photographs

Thanks for pointing it, I though I was the only one to think about just inverting colors. I really don't think they thought of this option, thanks for the hint. I tried on Google, Bing and DuckDuckGo and I confirm that searching "wikimedia foundation dark night mode invert" will not display a Dark mode is coming blog post.

Also, this non-existent blog post doesn't contain this ghostly paragraph on the subject of technical motivations and never-before-studied issues:

Editors control content which includes templates: amboxes, infoboxes, navboxes, as well as bitmaps, timelines, tables, and more. Some of those, like weather and sports tables, use colors in a meaningful, or semantic, way. Simply inverting these colors would immediately lose their meaning. We need to find other options.

Just hallucinations!

We need stability for communication to communities: are we talking about a night mode, or a dark mode? I read MediaWiki-extensions-DarkMode. But the WMF wrote this page: recommendations for night mode compatibility on Wikimedia wikis, initially named recommendations for dark mode compatibility on Wikimedia wikis. Also, the WMF published the "Dark mode is coming" blog post 4 days before the recommendations page rename.

I might being nitpicky here, but you know how noisy communities discussions can be.

@Lofhi https://www.mediawiki.org/w/index.php?title=Reading/Web/Accessibility_for_reading/Frequently_asked_questions#Why_is_it_called_%22Night_mode%22_and_not_dark_mode?

Corrected link: https://www.mediawiki.org/w/index.php?title=Reading/Web/Accessibility_for_reading/Frequently_asked_questions#Why_is_it_called_%22Night_mode%22_and_not_dark_mode?

On the subject of inverting colours, it is worth noting that while we try to uninvert colours of photographs with mw-no-invert, due to the way CSS hue transforms are calculated this always results in some distortion of the colours[1][2]. While this is subtle and acceptable for photographs, it is not really acceptable for instances where the colour is the information, e.g. on https://en.wikipedia.org/wiki/Pantone#Color_of_the_Year:

Original	Double inverted
	Note the slightly darker red of the shirt:
	2002, 2007, 2009 in particular:

1. https://stackoverflow.com/questions/76164156/css-revert-filter-with-invert1-and-hue-rotate180deg
2. https://stackoverflow.com/questions/19187905/why-doesnt-hue-rotation-by-180deg-and-180deg-yield-the-original-color

Thanks @Esanders !

Feel free to add any of this context to the existing FAQ question if you think it would be helpful!

There is something I don't understand @Esanders. Why are you uninverting the CSS filter on images? I will ask a very dumb question: why not using the not CSS selector to exclude img? For old browsers support?

In T26070#9131701, @Esanders wrote:

The solution here is to either add the classes used by the widget to the non-inversion selector, or to add the standard mw-no-invert class to the images.

The latter is a much better way to do this. Darkmode should not have to maintain a list of CSS classes by every extension that uses background images.

A newly-available solution here would be to use machine learning to classify images by whether they should be inverted. It is easy for a NN, for example, to recognize that those old photographs with faces should not be inverted even though their general lack of color would make them a good inversion candidate by most inversion heuristics.

A proof of concept of this as an API is now live at InvertOrNot.com, which uses a FLOSS-licensed NN (trained in large part on Commons images) to classify images by inversion status. It is pretty accurate, and only takes ~0.1s/image on a CPU & <20MB space, so running it at scale is possible.

I have been using it on my website mostly for improving the appearance of Wikipedia thumbnails in dark mode, and it has been working well. (InvertOrNot.com caches the classification; so we implement it as a background call on loading a WP article, and so if it's not fast enough to return the classification in time the first time an article is loaded, oh well, fall back to conservatively dimming the image, and its classification will be ready in time the next time.)

While it won't be perfect, error cases could be contributed upstream and the model updated eventually, in addition to marking them explicitly as invertible/non-invertible. (I would also point out that reliance on an API to classify images by URL would help avoid issues like double inversion where people or code loses track of metadata being threaded deeply throughout overlapping distant codebases and whether to negate or negate the negation etc.)

Thanks for sharing @Gwern, and for you work. It's undeniably a high-quality tool that could be shared with communities. Is it possible to host an instance on Toolforge? It would so appear on Toolhub.

@Gwern wonderful application, and agreed that this should be by URL and not by chain-of-reasoning.

In T26070#9667513, @Lofhi wrote:

Is it possible to host an instance on Toolforge? It would so appear on Toolhub.

Thanks, but I'm afraid I don't know what Toolhub is or what software it can easily host. I don't believe the developer, Mattis Megevand, uses anything particularly exotic: as you can see in the Github repo I linked, it's just PyTorch to train and Onnx to run/serve the model. So if Toolhub supports any nontrivial ML/DL tools from the past few years, I'd expect it to be able to host an instance...?

Megevand would be pleased to see Wikipedia use of InvertOrNot, so if there are any problems he can fix upstream, I'm sure he'd be happy to try to help.

Hello, as @Gwern said I would be happy to help.
Only requirements is to be able to use ONNX and NumPy, also as Gwern mentioned the model isn't perfect however it will improve over time.

The main challenge with automatically inverting any kind of image is that on our wikis there are many images which are semantically tied to non-images: for example consider a map of Europe with a key defined in a table where the table has colors that refer to parts of the map. In this situation if the map gets inverted, it now does not correspond with the key. For this reason, we have no plans to invert images at least in the initial version of the release.

I think any solution for marking an image as "invertable" should likely be done as part of the thumbnail processing as meta data perhaps as part of CommonsMetadata extension (which is maintained by another team than the one working on the night theme) - we'd need this information at time of rendering and doing it during rendering for all images would be too expensive so it will need to be cached.

you might try a mixture-of-classifiers, which all have an 'uncertain' range between yes and no:
0 - is precise color the point?
1 - does inversion look good in dark context?
2 - is there a color key in the text?
3 - other (non-standard inversion?)

@Gwern do you have a test set of images that are tricky and in particular need of care, for benchmarking?

You might like to ask community members dealing with the graphics in their project for advice.

you might try a mixture-of-classifiers, which all have an 'uncertain' range between yes and no:

Yeah, it's possible that more complicated categorizations will be necessary, but I'm not convinced it is yet. Even in the example of colored maps with separate keys - a colored map, which is colored by semantics, is something that can be recognized on its own without access to the key, necessarily. A colored map is clearly not 'just' a map, particularly if the coloring does not simply line up with the standard national boundaries. (In fact, if you're using something like CLIP, the model may have been pretrained *on* that pair already as WMF wikis will contribute a lot of paired data.)

do you have a test set of images that are tricky and in particular need of care, for benchmarking?

I don't because every time I have an error I just send it to Mattis (there's an API for reporting errors) and it gets added to the training data. I believe the current model doesn't reach 100%, so those could be used for testing.