When using "classX=skin-invert-image" on chemical structure images within multiple image templates to invert them for dark mode, a bug occurs such that the image becomes pure white or near-pure white rather than inverted. Here is an example:
I think the problem is that by default the multiple image template has a background color (white). Moreover, there is no way to remove the background or make it transparent. So it's not possible to fix this issue for now without modifying the template code. To fix this template, I'd suggest having a transparent background by default and only adding a background color when the background color field is used. Or, at the least, adding some way of having a transparent background to the template. Thank you. – AlyInWikiWonderland (talk, contribs) 03:43, 23 February 2026 (UTC)[reply]
It's possible that something changed in the HTML layout that broke these CSS selectors. For example, the regular File: syntax (see two of File:Example.svg on the right) produces a <figure> tag with the attribute class="mw-default-size skin-invert-image", but the demo of {{Multiple image}} above produces a <span class="skin-invert-image" ...>.
@Andrybak and AlyInWikiWonderland: I got it all working after spending an unhealthy amount of time on it (note that me adding the sandbox example here overrides the css of the one above):
{{Multiple image/sandbox| align = center | header = Chemical structures of psychedelics | image1 =Psilocybin, Kekulé, skeletal formula of canonical psilocybin.svg | width1 = 225px | class1 = skin-invert-image |caption1 =[[Psilocybin]]| image2 = Psilocybin_zwitterion_3D_ball.png | width2 = 150px | class2 = bg-transparent |caption2 = Psilocybin in 3D }}
The problem lies in the .thumbimage class, which was forcing a white background at a higher level even though the images lower down were not having it set. |image_style=background-color: overrides that value, but it is the ultimate reason why image backgrounds default to white, regardless of skin mode.
If we want the backgrounds of the ones without |class=bg-transparent to be black like File: ... |thumb, I could do that too, but this matches how they appear in infoboxes. |image_style=background-color: continues to work as intended, even in combination with skinverts. This also allows |class=bg-transparent to work correctly in light mode. ~ oklopfer (💬) 07:54, 24 March 2026 (UTC)[reply]
|background color also now has aliases |background_color (i.e. with proper formatting) and |bg_color. The former (with the space rather than underscore) should be considered deprecated and cleaned up wherever it appears IMO.
Also fixed the issue of the background color bleeding all the way across the page instead of just applying to the box.
Here's an example of the template with parameters for both height and width. Note that a value for the parameter |total_width= is required. —andrybak (talk) 22:44, 31 January 2026 (UTC)[reply]
I noticed images wrapping to new lines with this template when on mobile. Setting total_width to 360 (or 365) made it display as anticipated. Maybe this should be suggested somewhere; I changed one example width in the documentation from 400 to 360 in case it helps in other places and thought I'd also draw attention to it here. Chchowmein (talk) 23:58, 17 March 2026 (UTC)[reply]
Description of suggested change:
Multiple updates; the primary purpose of these changes is to fix dark mode implementation, and as a secondary, fixing background color implementation. I have split this into two sections for the two components that need updating.
The .thumbimage class forces an unwanted white background, which the current CSS exclusion rules do not prevent, and can only at present be worked around with the |image_style parameter (which sets style=background-color: for .thumbimage). The following change repairs this, using this logic:
At base, all .thumbimage classes are now set to inherit the background color, overriding the undesired white background
Modifying the old exclusion logic, which applied a white background lower down if .skin-invert, .skin-invert-image, .bg-transparent were not used:
For .skin-theme-clientpref-night and .skin-theme-clientpref-os+prefers-color-scheme: dark: now additionally check if .thumbimage has a style=background-color: application, and apply the white background only if this is also not used (in combination with the prior checks).
For .skin-theme-clientpref-day: use the same logic as above, but without .skin-invert, .skin-invert-image exclusion (i.e. apply the white background in every case except for situations with .bg-transparent or style=background-color:).
While the above repairs dark mode display of images, two other issues are apparent, which occur on all skin types:
Caption/header/footer text blends in when darker backgrounds are used
The |background color= parameter applies at too high of a level, causing the color to display outside of the multi-image box and span across the page (it also uses nonstandard formatting, with a space in the parameter instead of an underscore)
Introduce a new |color= parameter (alias |text_color=) which may be used to adjust when using darker backgrounds (must be applied at multiple levels within the module to work consistently: :root, div, captiondiv, footer)
Remove the :root level application of |background color= so that it only applies further down, inside of the box (also add aliases |background_color= and |bg_color=)
With all of these changes combined, the template finally handles dark mode and background colors correctly. Thank you! ~ oklopfer (💬) 14:56, 25 March 2026 (UTC)[reply]
@Redrose64 it's been in the sandbox too, and with numerous test cases on the page, as I explicitly mentioned here. I wouldn't have made the request if I had not already rigorously tested there. I just used the edit request template, which prompted me to enter the diff. I don't really appreciate the suggested incompetence if you aren't going to check that it had already been done.
This edit request has been answered. Set the |answered= parameter to no to reactivate your request.
Description of suggested change:
I would like to suggest a total_height parameter be added to the template. It would allow for some templates to more properly align with all page elements without compromising images.
Can we give this an option to reflect the user's preferences? If the size is less than, say, n = 10, could we engineer it so that this is equivalent to "upright=n"? We could then set the size to 1 to fit most other images in the article. — kwami (talk) 20:32, 16 May 2026 (UTC)[reply]
Actually, partially scratch that. I am noticing the issue you described occurs when editing a page, but not when regularly viewing the page, even when logged in. ~ oklopfer (💬) 20:16, 21 May 2026 (UTC)[reply]
While noticing a bot removing the last image from a template usage, I noticed that there is no indication that the template is now useless on that page. Could a tracking category be added if there are no images being used? Gonnym (talk) 06:23, 28 May 2026 (UTC)[reply]
Please link to a page where this is happening. The template's /testcases page could be a good place to demonstrate the problem. – Jonesey95 (talk) 00:35, 3 June 2026 (UTC)[reply]
Done already. Santiago Claudio (talk) 08:25, 18 April 2026 (UTC)
Not done: please make your requested changes to the template's sandbox first. See WP:TESTCASES. – Jonesey95 (talk) 04:46, 17 April 2026 (UTC)