| LGoto | |
| Aug 3 2022, 8:45 PM |
| F70085263: Screenshot_20251110-162337.png | |
| Nov 10 2025, 9:31 PM |
| F70084495: IMG_7086.jpg | |
| Nov 10 2025, 8:55 PM |
| F70084513: Screenshot_20251110-121201.png | |
| Nov 10 2025, 8:55 PM |
| F70084515: Screenshot_20251110-121145.png | |
| Nov 10 2025, 8:55 PM |
| F70084514: Screenshot_20251110-121153.png | |
| Nov 10 2025, 8:55 PM |
| F35410283: Screenshot_20220727-114924.png | |
| Aug 8 2022, 2:59 PM |
Example:
What happens?:
What should have happened instead?:
Some contrast to see logo
Software version
2.750416-r-2022-07-27 Android
Other information (browser name/version, screenshots, etc.):
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Dbrant | T252904 Content issues with dark mode / non-white reading themes when rendered on mobilesapps / page content service | |||
| Resolved | Dbrant | T369435 Update PCS to no longer store local copies of styles | |||
| Resolved | BUG REPORT | Dbrant | T314536 Images with dark content and transparent background appear unreadable in Dark Mode |
@LGoto, @JTannerWMF this doesn't look like a bug per se, as the logo is a transparent PNG. The issue would also happen if we were in light mode and the logo happened to have white text on a transparent background. Is there a chance we can reach out to the community and have them add an actual background to the image?
Is there a chance we can reach out to the community and have them add an actual background to the image?
But this would make a white picture show instead, which is not very nice too. Besides I think transparent background was always kinda preferable for certain kinds of images.
Is it possible to somehow detect when this would happen for an image and add some generic light background?
I feel it bears mentioning that with SVGs, a solution to this is potentially trivial: at least with fills and strokes that are set to currentColor (and possibly also those that are left unset or set to #000) it would fix the vast majority of issues to simply display those SVG elements as white instead.
@Dbrant this is working on web. Is it also fixed in the app now or does the app need to add support for skin-invert-image?
A VRT customer reported this similar issue with a SVG image (File:Tianeptine2DACS.svg)
See on-page here: https://en.wikipedia.org/wiki/Tianeptine?vectornightmode=1&safemode=1&useskin=vector-2022
Hey @Xaosflux this is for apps - we are evaluating a possible generic solution in T370074 given the amount of feedback about this isuse we're seeing on https://www.mediawiki.org/wiki/Reading/Web/Accessibility_for_reading/Reporting
Looks good on 2.7.50543-r-2025-07-31
Tested on Pixel 6 on Android 15 and OnePlus 8 on Android 13. Tested on article with dark images with transparent backgrounds.
Reopening this one based on some user feedback highlighted by @ARamadan-WMF.
Testing on iOS 7.8.5 (5873) and 2.7.50554-alpha-2025-11-03
Note: On both apps, the image looks fine in light themes
Android
iOS
Quick reminder @ABorbaWMF @ARamadan-WMF
For dark mode issues that appear specific to an individual article, it is very likely to be resolved by making an edit to the article itself.
Observe that the image you highlighted above also looks incorrect in mobile web:
...meaning that the article (or any transcluded templates) itself should be edited to be more compatible with dark mode (on web and apps). The likely solution is to add a skin-invert-image class to the image.
With all due respect, article editors should not have the burden of making the content compatible with light/dark mode. The underlying system/app should be the one responsible of this.
Of course, and we're trying to reduce the burden as much as possible; In most cases the dark mode logic is indeed handled automatically. But unfortunately there will be a small number of edge cases where a CSS class must be added manually.
In the specific case of inverting the colors of certain images, our logic simply has no way of knowing whether an image should be inverted or not, therefore it requires a "hint" by the editor, in the form of the skin-invert-image class.
(See also our full list of recommendations for keeping articles streamlined for compatibility)