Page MenuHomePhabricator

[GOAL] Provide a dark / night mode skin or theme
Open, In Progress, HighPublicFeature

Assigned To
None
Authored By
Platonides
Jun 22 2010, 12:05 PM
Referenced Files
F42152609: image.png
Feb 26 2024, 5:55 PM
F42152593: image.png
Feb 26 2024, 5:55 PM
F42152575: image.png
Feb 26 2024, 5:55 PM
F42152544: image.png
Feb 26 2024, 5:55 PM
F42152365: image.png
Feb 26 2024, 5:55 PM
F42152353: image.png
Feb 26 2024, 5:55 PM
F35789835: image.png
Nov 17 2022, 10:57 AM
F31520126: MediaWiki dark theme - main-page-2.png
Jan 21 2020, 10:06 PM
Tokens
"Like" token, awarded by gymate."Like" token, awarded by Bugreporter2."Hungry Hippo" token, awarded by Don-vip."Hungry Hippo" token, awarded by Sj."The World Burns" token, awarded by czar.

Description

There have been several instances of feedback asking for a "dark version" (dark background, light text). I don't know if vector tires the eyesight more than monobook or it's simply that they now have a way to ask for it, but the petition was higher than I expected.

Probably more appropiate to provide as an alternate stylesheet than a separate skin, though. I wouldn't be surprised if some wikipedian already designed it.

http://es.wikipedia.org/w/index.php?title=Wikipedia:Comentarios_sobre_experiencia_de_usuario&diff=37939214&oldid=37938825

http://es.wikipedia.org/w/index.php?title=Wikipedia:Comentarios_sobre_experiencia_de_usuario&diff=38075969&oldid=38073560

http://es.wikipedia.org/w/index.php?title=Wikipedia:Comentarios_sobre_experiencia_de_usuario&diff=38246256&oldid=38216451

Related projects

WMF-developed dark-mode userscript usable since October 2019, showing complementer colors with the css rule transform: invert(1)and specific cases fine-tuned for legibility.
Dark-Mode project to implement this in MediaWiki.
T122924: Merge Extension:Theme into core
Skin themes – dark and gray themes for Timeless and Vector skins. Custom color palette, similar to discord's colors. Experimental volunteer project: there is some content that's hard to read with it.

Wishlist Survey: Night mode


Version: 1.21.x
Severity: enhancement

Developer notes

  • To get here we'll likely want to get to a place that skin.variables can be swapped out for a dark equivalent e.g. skin.variables.dark
  • The dark mode would be applied via a prefers-color-scheme CSS @media feature.
  • ResourceLoader would likely need some support to toggle between dark and non-dark mode.

Details

Reference
bz24070

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Separate/different topics should go to separate tickets.

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:

image.png (492×504 px, 87 KB)

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

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:

image.png (492×504 px, 87 KB)

(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.

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?

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:

image.png (492×504 px, 87 KB)

(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!

Jdlrobson renamed this task from Provide a dark / night mode skin or theme to [GOAL] Provide a dark / night mode skin or theme.Feb 22 2024, 4:38 PM
Jdlrobson changed the task status from Open to In Progress.
Jdlrobson raised the priority of this task from Medium to High.

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.

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:

OriginalDouble inverted
image.png (361×419 px, 150 KB)
image.png (361×419 px, 150 KB)
Note the slightly darker red of the shirt:
image.png (282×410 px, 190 KB)
image.png (282×410 px, 190 KB)
2002, 2007, 2009 in particular:
image.png (662×709 px, 45 KB)
image.png (662×709 px, 45 KB)
  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?

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.

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.