I did some spelunking out of curiosity, and the background for the light mode was changed in 2023 with https://gerrit.wikimedia.org/r/c/mediawiki/core/+/969953 (it was previously defined to be pure white using the @background-color-thumbimage-screen variable, which was removed in that patch). I can't tell whether that was a mistake or an intentional design change.

I don't know what's going on in dark mode, I haven't tried to investigate.

Probably looking for T370074: Apply a default background to images in night mode for motivation, though tracing those changes to where the system stands now is an exercise for the reader, and whether those changes are the changes you're specifically concerned about in context.

Hmm, so I guess it's intentional that images in dark mode have a "middle" grey background, in order to support drawings that were designed with a light background in mind. That's a tricky design decision with some tradeoffs, but I see how it makes sense.

In light mode though, I'm pretty sure that the change was unintentional. And in dark mode with class=skin-invert something is definitely wrong, and using it is currently recommended in https://www.mediawiki.org/wiki/Recommendations_for_night_mode_compatibility_on_Wikimedia_wikis#Apply_filters_to_dark_images_with_transparent_background.

The idea of using color-disabled as background was bad to begin with. Because this color is supposed to have sufficient contrast w.r.t. white, and thus there is a great chance that it can be used for meaningful elements in drawings, so placing them on such background would make these elements invisible (as can be seen in the example). But it is, not surprisingly, very much in line with the silly modern fashion when light themes use gray text on white background (poor readability with excessive brightness) instead of black text of light-gray background (good readability with comfortable brightness). The proper way to avoid bright white spots in dark mode would be to use normal white background under the image and then reduce the overall lightness by something like filter:brightness(80%), similarly to the class=skin-invert mechanism (either by default, with a possibility to override by class=skin-dont-dim, or as an option with class=skin-dim). This would also work consistently for images that have hard-coded white background, as opposed to the current mess when images with and without background are used (see https://en.wikipedia.org/wiki/Oblique_projection#Examples for an example; it's a gallery but has the same problem).

Here is an illustration of the proposed change described above (for the dark mode; the light mode is obvious) from the same page edited in DOM/style inspector ("Current" is the same as "Plain" in the original):

@MikhailRyazanov Do I understand correctly that you'd apply the dimming to photos as well?

@matmarex Probably not automatically. I mean, some very bright photos could look too harsh on a dark page and might benefit from dimming (case-by-case), but generally good photos have reasonable average lightness to avoid overexposure within the display dynamic range an look fine on both light and dark backgrounds.

So the simplest approach would be to make dimming an explicit option (like skin-invert), which will require more work on wiki pages but will not produce unexpectedly inconsistent results. On the other hand, applying automatic dimming only to non-JPEG images might be a sufficiently good heuristic (most photos are currently in the JPEG format, and most non-photos must not be in the JPEG format), which will then require relatively small case-by-case corrections for false positives and false negatives.

Thanks for the discussion here @matmarex and @MikhailRyazanov.

Hmm, so I guess it's intentional that images in dark mode have a "middle" grey background, in order to support drawings that were designed with a light background in mind. That's a tricky design decision with some tradeoffs, but I see how it makes sense.

That's exactly right. The black drawings on a black background was one of the most widespread bugs that came out of the dark mode changes. I had to choose an existing design token that would create the fewest contrast errors. The thought was that, since all of those transparent SVGs with black lines were drawn for a white background, instances where the middle grey would create contrast issues would be relatively rare. The ADSR example above is a good example of the middle grey creating a contrast issue. Of course, we don't have any way to check how many errors like that exist.

In light mode though, I'm pretty sure that the change was unintentional.

Correct. That's a bug. The change was only intended for dark mode.

And in dark mode with class=skin-invert something is definitely wrong, and using it is currently recommended in https://www.mediawiki.org/wiki/Recommendations_for_night_mode_compatibility_on_Wikimedia_wikis#Apply_filters_to_dark_images_with_transparent_background.

The instructions could have been clearer here, but this invert hack was only intended for images that are completely black or dark grey like signatures or black logos. This approach should obviously be avoided in any case where any colours other than black are used in the original image because that would distort any semantic use of colour in the original.

The proper way to avoid bright white spots in dark mode would be to use normal white background under the image and then reduce the overall lightness by something like filter:brightness(80%)

This is a really elegant solution to the problem. I hadn't considered a brightness filter. It removes the bright spots and maintains the semantic colour usage.

applying automatic dimming only to non-JPEG images might be a sufficiently good heuristic (most photos are currently in the JPEG format, and most non-photos must not be in the JPEG format), which will then require relatively small case-by-case corrections for false positives and false negatives.

I agree most of these images are SVGs. Again, we can't tell for sure how many errors this would create, so I'm not sure that it would create fewer issues than the current grey background solve. I think you're probably right that the filter would have fewer edge cases than the mid-grey, though.

@Jdlrobson what do you think?

Okay, I've updated T388197 for the dark mode issue.

For this ticket, I recommend this is routed to the design system team to make a decision about which token this should use first (it sounds like we are leaning towards @background-color-base-fixed). I've updated the ticket based on what we've learned so far.

In T387543#10611971, @Jdlrobson-WMF wrote:

Okay, I've updated T388197 for the dark mode issue.

For this ticket, I recommend this is routed to the design system team to make a decision about which token this should use first (it sounds like we are leaning towards @background-color-base-fixed). I've updated the ticket based on what we've learned so far.

Design-System-Team discussed this and yes, we would recommend using @background-color-base-fixed because that's what's used in the Codex Thumbnail for exactly this use case. That said, you all know more than we do about the different images that could appear, so there may be a reason to go with a different color.

Change #1127112 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/core@master] Set thumbnail image background to @background-color-base-fixed (white)

https://gerrit.wikimedia.org/r/1127112

In T387543#10631081, @Jdlrobson-WMF wrote:

Okay thanks for input! Web team can handle implementation in T388197

Can you clarify what you mean by this? Should I abandon my attempt to resolve this task?

Note that my patch does not resolve T388197, only this task. (I'm not trying to redo the dark mode support, only trying to fix the background color regression in default mode.)

In T387543#10636997, @matmarex wrote:

In T387543#10631081, @Jdlrobson-WMF wrote:

Okay thanks for input! Web team can handle implementation in T388197

Can you clarify what you mean by this? Should I abandon my attempt to resolve this task?

No the patch is very useful thank you, that's why I moved it to the new task.

Note that my patch does not resolve T388197, only this task. (I'm not trying to redo the dark mode support, only trying to fix the background color regression in default mode.)

Understood. I checked with Chris and he said web team should review. It makes sense for web team to work on all the issues in T388197 together so we don't make any mistakes or create work for us in the long run. I suspect what that means is we'll write the patch for dark mode and then merge yours along with it. Team just estimated that work and I'm waiting on Olga to determine priority and when we should do that.

I see, thanks for explaining.