Talk:Recommendations for night mode compatibility on Wikimedia wikis

User perspective (not an editor)

Jdlrobson. Examples have already been provided on the tickets you’ve closed. I also asked if you’d be open to a quick teams/zoom call. You unsubscribed from the ticket you closed so not sure if you even saw the responses I tagged you on right before Ijm8710 (talk) 17:19, 5 October 2023 (UTC)

Hi @Ijm8710 thanks for writing here. Firstly I have nothing to do with the apps team, so lack the context of the bug report or the bugs you've experienced previously. I work on web products, with my main focus being the Minerva and Vector skins. Since articles change, many of the examples I found in the task are outdated. It would be helpful for you to provide me some recent examples so I can see what we can do there. The purpose of this page is to gather and evolve best practices with community members in the editor community (@Izno I want to note you may have different opinions from me on where the boundaries lie and I want to make clear that's expected and the aim is consensus building).

Apologies if this is a little technical: but since you identify as a non-editor you may not be aware of the unusual relationship between software and content - content and its styles tend to be managed on wiki and the chrome (the menus etc) by software maintainers, because of this it can be challenging to agree to specific solutions and sometimes impossible to fix things without the two groups together in conversation or without adding significant technical debt (something I'm trying to remedy with this page). Jdlrobson (talk) 17:44, 5 October 2023 (UTC)

I’ll provide a subset of examples in the next few days but I just want to make sure I’m not wasting my time. I did all this aggregation quite a few times only for it to go nowhere. I understand how you note you’re more on the web side rather than the app side but it sounds like you want to approach them in unison. I don’t expect the fixes to take days but if I put in the work to aggregate examples, is it realistic to hit on some of the bigger templates (the ones that affect huge bulks of athletes/episode pages) within the end of this calendar year?

and regarding the question I’ve raised several times over the years, is there not a way to use darkness of background to dictate text color being applied as white or black. Obviously I’m over simplifying it but atleast to some degree I just can’t fathom why that can’t provide at least a better start.

are you or whomever is most responsible for this issue open to a zoom/teams meet. Can be quick (say 15 minutes)

lastly, being that I’ve never really used talk pages, is there a way to get alerted to replies in the same way I can for phabricators I’m tagged on. This is the main reason I was hesitant to move from there Ijm8710 (talk) 17:58, 5 October 2023 (UTC)

@Ijm8710: Yes, just press the Subscribe button below the topic header (next to the topic header on desktop) to get notifications about replies in the given topic. (Unlike Phabricator, it’s not public who’s subscribed, and one cannot subscribe or unsubscribe others.) You can configure in your notification preferences whether you want to get email and/or web (little drawer icon at the top of the page) notifications. —Tacsipacsi (talk) 12:47, 6 October 2023 (UTC)

Also one other question. Is there someone who is the main pm from the apps perspective? Jmimor and seddon seem to be in that capacity potentially. I’ve got sssurances from seddon a bit ago he was working on this. Was disappointing to find we’re starting anew. Curious who is essentially the lead for the apps-specifically ios for me being of interest Ijm8710 (talk) 18:02, 5 October 2023 (UTC)

Hi @Ijm8710, thank you for all of the energy and effort you've put into sharing your thoughts. I'm Jaz, the Product Manager (PM) for the apps. For context, I was the Product Manager on Android, and in the last few months became the Lead PM for both apps. Jminor is no longer with the Foundation. Seddon is the Engineering Manager for the apps and was managing some of the Dark Mode work on apps when we had engineering contractor resources dedicated to fixing some of that work, so he was pretty in the weeds on the issues with dark mode during that time. The contractor's work with the Foundation unfortunately ended in the summer. I want to fully acknowledge that just because the contract work ended, it doesn't mean all of the issues with dark mode on apps are resolved. It just means we do not at present have engineering resources specifically dedicated to this problem area on the apps. We certainly should have communicated with you why the tickets became inactive. I agree with you the ticket that was closed, should be open because the issue is not resolved. I will fix that today.

Now I am still catching up on everything you've previously suggested to remedy some of the dark mode issues. I do not want you to have to repeat yourself in several places and I want to have appropriate context. While I appreciate you've waited a while for a response, I'd appreciate a bit more grace as I fully catch up. I will provide a full response based on what you've historically shared by the end of next week.

In the meantime, there are some more immediate things that I can share. First, we will have office hours the 27th of October at 5 p.m. UTC. Seddon and I will both be in attendance. I hope you can make it, I agree there is nothing like synchronous communication. You can see the full details of our office hours and see what other topics people have suggested that we cover during that time on our Office Hours MediaWiki page. I will ensure dark mode is a topic we prioritize during office hours if you join. I am also tagging @ARamadan-WMF, our community relations specialist, so that she can follow this conversation and ensure you're subscribed to our team newsletter. I saw that you are keen on updates from our team, that is one of the structured places we share them. If I am ever slow to respond because I am out of office, slammed with meetings, or at an event, please reach out to her. I am also tagging @OVasileva (WMF), she is the Product Manager for the Web team and responsible for all things related to Desktop and Mobile Web. She is the driver of the dark mode effort for our organization's Annual Plan this year, some of which may have implications for the apps and some of which do not. @Jdlrobson is an engineer on the Web team alongside Olga and he is essentially just trying to make sense of the cross platform issues of dark mode since they are starting this work based on the organization's annual plan. He recently started drafting documentation based on various issue areas and possible approaches, which is what you see here. Our annual plan is what drives what gets prioritized by the organization in a given year and what does not. It may be helpful to give it a read to get an idea of the focus areas this year. Also, Olga can share more about how they are thinking about dark mode on Web in regards to that Annual Plan, as well as other accessibility changes they are planning. She can also share how you can stay informed with their team's work holistically so that you may be able to weigh in as they make decisions that impact readers. Again, depending on their approach and capacity, their work could have implications for the apps or not touch it at all, nothing has been officially decided when it comes to an approach.

Once I have a chance to catch up on what you've previously shared and sync with Seddon, Olga, and Jon, I will check back in here next week.

Thanks again for your patience! JTanner (WMF) (talk) 16:15, 6 October 2023 (UTC)

@Ijm8710 Thank you again for your patience as I gained context on your previous requests and concerns.I see you have a suggestion of changing the way we do search on apps. I will have @ARamadan-WMF break this out as a specific task so that we can discuss it as a team and have it triaged. We will have you subscribed so you can track the discussion.

Regarding the readability issues, all of the issues you identified is work that would have to be prioritized by the Content Transform team or MediaWiki Platform team. You can get a glimpse into the Content Transform Team's current work here. As I mentioned earlier, Seddon temporarily had engineering support for fixes at a PCS layer; that responsibility now rests with those teams. I can imagine that is a disappointing answer. I do not want your concerns to fall by the waste side, so I will ensure the PMs of those teams aware of this situation. However, I do want to highlight the time it would take for them to adhoc fix each issue and edge case (which is the approach we had when you first reached out) could actually be fixed systemically with the work theWeb team is planning to do. As they firm up their approach within the next few weeks, that will become clearer. I would wager that the outcome of the conversation amongst teams will be to wait for the Web team’s work, which is scheduled to happen this fiscal year (released by July 2024). Actually, any adhoc fixes done by Content Transform or the MediaWiki Platform team, could potentially be undone with the work the Web team is planning to do.

JTanner (WMF) (talk) 21:26, 26 October 2023 (UTC)

Hello all,

The mentioned suggestion now is on this ticket T350574.

I also added you, @Ijm8710, as a subscriber. ARamadan-WMF (talk) 11:46, 6 November 2023 (UTC)

Hello @Ijm8710!

I am Amal, the Community Relations Specialist supporting the apps team; I wanted to extend a warm welcome to you.

Feel free to reach out for any future communications or questions you may have. You can also subscribe to our newsletter to stay updated with our team's latest developments.

We would love to have you join us at our next office hour as Jazmin explained, scheduled for the 27th of October. It's a great opportunity for synchronous communication.

Looking forward to connecting with you further!

ARamadan-WMF (talk) 16:10, 10 October 2023 (UTC)

mw-no-invert and notheme

This has come up in a few discussions I've had so far around dark mode, most recently with User:Izno. These 2 classes seem similar but are subtly different given the different approaches used by apps and gadgets.

We plan to introduce dark mode to web and hope to resolve this in future as we evolve the draft of this page. This may mean removing the need for these classes, or standardizing on a more common and descriptive class.

At time of writing, the web mode is likely to use CSS variables, which will avoid the need for the inline style rewriting done in apps and the imperfect inverting of gadgets so it's possible the recommendations will change in future. Jdlrobson (talk) 17:23, 5 October 2023 (UTC)

See also T345281, which also introduces mw-invert. ESanders (WMF) (talk) 10:35, 21 October 2023 (UTC)

Night = B&W?

Great to see some of these recs and examples of template-specific css.

• Could you add a list of skin-provided classes with their own light/dark-theme colors?
• The examples in T352462 are fully black-and-white; is that the aim of night mode?

Sj (talk) 00:26, 11 December 2023 (UTC)

We are still in the research phase and no decisions have been made yet.

The recommendations here currently cater for the gadget and mobile apps. It is likely to evolve once we make a decision around how to build this in web.

Questions and concerns relating to that research are very much welcome on our Phabricator tickets! Jdlrobson (talk) 06:33, 13 December 2023 (UTC)

CSS variable to set background color without setting text color

I’ve updated a default gadget on huwiki to use --background-color-error-subtle to set the background color of disambiguation page links. I haven’t set a text color because I want the links to use the default link color, whichever that may be (#36c on Vector 2022, #0645ad on Vector 2010, #236 on Cologne Blue etc.). Is using a CSS variable enough, or does Recommendations for night mode compatibility on Wikimedia wikis#Always define color when defining background still apply? —Tacsipacsi (talk) 19:53, 13 March 2024 (UTC)

Hey @Tacsipacsi yes that's enough. This actually follows the other guideline at use CSS variables or CSS design tokens where possible.

Does this edit clarify things or can you suggest a better edit?

Thanks for making a start to Hungarian Wikipedia's dark mode preparations! Much appreciated! Jdlrobson (talk) 22:36, 15 March 2024 (UTC)

@Jdlrobson: Thanks for the edit! Yes, the current version is clear. In the previous one, it wasn’t clear to me whether the two sections have an and or an or connection. —Tacsipacsi (talk) 00:58, 16 March 2024 (UTC)

Nesting or :is selector for the good

Had my stab at night mode support in a template. It was not terrible, but could be better :). It would help to be able to take some shortcuts with new CSS features.

So CSS Nesting made it to browsers in early 2023 and also nesting is part of Baseline 2023, sadly not part of Windows 7 which was abandoned before that... So, you might want to check the stats for Windows 7, I guess, but also, I think dark mode is something Windows 7 users can live without ;).

Another great feature to support would be the :is selector (part of a much larger Baseline). So, for example, instead of two or more lines, I could just use one selector:

/* old, boring tedious ;) */
html.skin-theme-clientpref-os .tpl-polska .NavToggle::before,
html.skin-theme-clientpref-os .tpl-polska .NavToggle::after,
html.skin-theme-clientpref-os .tpl-polska .NavHead {
	background-color: black;
	color: white;
}
/* :is */
html.skin-theme-clientpref-os .tpl-polska :is(.NavToggle::before, .NavToggle::after, .NavHead) {
	background-color: black;
	color: white;
}
/* nesting */
html.skin-theme-clientpref-os .tpl-polska {
	.NavToggle::before, .NavToggle::after, .NavHead
	{
		background-color: black;
		color: white;
	}
}

I know this would require non-trivial changes to CSS sanitization and TemplateStyles, I think CSS nesting would be hard, but having these features would help a lot in migrating to night mode. Maybe you could bump priority on any of this? Nux (talk) 22:55, 21 March 2024 (UTC)

There is a conversation going on about dropping IE11 support which I think would help this cause :-)

Thanks for the hint! I think this is also something French Wikipedia have been doing are considering browser support as part of those changes? https://fr.wikipedia.org/wiki/MediaWiki:Gadget-Mobile.css#L-157 Jdlrobson (talk) 03:48, 23 March 2024 (UTC)

@Nux Just to get some perspective, we generally strive towards 6-8 years or so of backwards compatibility (especially for CSS). That means anything introduced in 2023, can take up to 2030 before you can depend on it, especially for syntax changes like those of nesting. IF this is going to arrive before that time, it is more likely via a less to css transpiling pipeline (but these tend to be really slow, so might not be possible). Something like :is() is not a syntax change, so you likely be able to use it sooner, but you should probably only use it for progressive enhancement and not for critical styling. —TheDJ (Not WMF) (talk • contribs) 13:44, 3 July 2024 (UTC)

Invert or Not API

See https://phabricator.wikimedia.org/T26070#9667442 for details of an available API for deciding whether or not to invert an image. The current and proposed tools might want to take advantage of or host such a service. Sj (talk) 22:21, 31 March 2024 (UTC)

Class skin-invert flipped the caption colors

Hi. I encountered a problem when trying to fix one image at Enwiki. I'm not sure if it's an Enwiki problem, a code error, or a docs error.

• Following the docs here…
• I added |class=skin-invert to this image at w:Pi
• It worked for the image, but it inverted the color of the caption-text/-background, too. (screenshot) Hence I reverted myself.

Relatedly, I was unsure what that docs section means by "or apply a background color of white to the image". I suspect it means "upload a new version of the file with a non-transparent background", but perhaps there is some other CSS technique? Please clarify in the docs. Thanks! –Quiddity (talk) 00:44, 17 May 2024 (UTC)

I think this might be phab:T365102 ? Jdlrobson (talk) 01:23, 17 May 2024 (UTC)

Thanks for the pointer and the docs-edit! For the edit, unfortunately that `background:white` solution didn't work for this example; I think perhaps because it's an SVG? Searching phab it appears that phab:T332653 might cover this issue. Hope that helps. –Quiddity (talk) 03:39, 17 May 2024 (UTC)

Apply skin-invert class with Hiero extension

Hiero extension transform alphanumeric codes into unicode icons in order to draw Hieroglyphycs for Pharaon names. You can see templates as Template:Infobox_pharaoh/Serekh or Template:Pharaon_hiero_draw that call for it.

The code includes calls to the hiero extension and, in some case, complement it with images. In these images I applied successfully the class=skin-invert. But I don't know where and how to make the inversion for the hiero results.

Example in Ramsès_II infobox.

Thanks Amadalvarez (talk) 16:28, 31 May 2024 (UTC)

thanks this issue will require a change in the associated extension

Tracked in Phabricator
Task T366384

Patches welcome! Jdlrobson (talk) 19:34, 31 May 2024 (UTC)

@Jdlrobson, Thanks !. Amadalvarez (talk) 20:02, 31 May 2024 (UTC)

Hi @Jdlrobson. It seems that it's already fixed. Is it?.

I appologize but i don't know how to apply the solution (frankly, Phabricator talk style is cryptic to me).

Thanks for your help. Amadalvarez (talk) 14:24, 2 July 2024 (UTC)

Hi @Amadalvarez yes a fix is currently riding the current deployment train and will be applied across all wikis come Thursday! No need to do anything on the template side! Jon (WMF) (talk) 23:18, 2 July 2024 (UTC)

Thanks, @Jdlrobson, @Jon (WMF)

It's running  !! Amadalvarez (talk) 22:03, 12 July 2024 (UTC)

How to know the theme in use ?

Is there a "magic word" or similar to know which option, dark/light, is currently selected? The question arises in the context of a WP, specifically in the infoboxes, to be able to act differently, beyond the aspects that the platform automatically does.

The present case I have: decide which image (mainly, logo image (P154) to get from Wikidata based on the value of the qualifier for color scheme (P8798). See NJ/NY Gotham FC (Q1447181) or FC Cincinnati (Q20855983), for instance.

Thanks, Amadalvarez (talk) 03:43, 5 June 2024 (UTC)

Hi @Amadalvarez! I may be misunderstanding your question, but this section details recommendations for targeting styles specifically to night mode, including in infoboxes. If this is not helpful, I'm more than happy to answer any other questions you may have ☺️ SToyofuku-WMF (talk) 20:13, 5 June 2024 (UTC)

I try rewording it. Some logos have two designs, one for dark-on-light color scheme and one for light-on-dark, that is two files. Using the dark-on-light file with skin-invert can result quite different from the desired light-on-dark file in dark mode. See a test at https://ca.wikipedia.org/w/index.php?title=Plantilla:Sandbox&oldid=33584606. The question is how to change from one file to another one according to the theme. Vriullop (talk) 07:05, 6 June 2024 (UTC)

I see - not sure whether we support that capability, but let me check with the team and get back to you SToyofuku-WMF (talk) 20:22, 6 June 2024 (UTC)

I’d probably just add both and apply display:none on the wrong one – even if wikitext could access the same information as .skin-theme-clientpref-night (it’s unlikely that it will ever be able to do so, as that would fragment the cache, significantly increasing the storage need of WMF), the @media query is definitely unavailable at server side and can probably even change without a page reload (e.g. if the user toggles the dark mode of the device). —Tacsipacsi (talk) 22:19, 6 June 2024 (UTC)

Thanks, it's fine to me and it seems the best feasible option. In the next thread there is an example with this approach. Vriullop (talk) 06:42, 9 June 2024 (UTC)

A similar suggestion made by my colleague:

You could try updating the background image in CSS conditionally based on the classes described in the page I linked. One caveat is it seems like you're looking for native SVG rendering support, which is currently not available SToyofuku-WMF (talk) 23:10, 6 June 2024 (UTC)

The problem with this approach is that the logo is not a background image. It’s content, which needs alternative text, needs links to the file description page for readers’ convenience and often for copyright reasons (although the NJ/NY Gotham FC and FC Cincinnati logos are PD, so copyright doesn’t mandate the links), needs to be copyable and printable. And, actually, it’s not technically possible either: you can’t access Wikidata statements in TemplateStyles stylesheets, and can’t use @media queries or <body> classes in inline CSS. —Tacsipacsi (talk) 19:51, 7 June 2024 (UTC)

Using a Different Image in Dark Mode with a Template

Hello,

Is it a good idea to use a template like fr:Template:Contenu clair sombre that I created which switches between two images depending on whether light or dark mode is being used ?

This approach would allow for more refined adaptation of images beyond simply inverting colors or adding a white background. (This template can function with elements other than images, but I don't see what other things than images need more than what CSS styling alone can achieve). Escargot bleu (talk) 10:37, 8 June 2024 (UTC)

Note that this is the same subject discussed in the previous thread. Vriullop (talk) 07:05, 9 June 2024 (UTC)

Response to "Add suggestion for non-invertible images"

@SToyofuku-WMF what I'm missing in your suggestion is the preferred way to do that, how can I add a background to a thumbnail with a transparent SVG which doesn't break the rest of the page? Sjoerddebruin (talk) 15:09, 11 July 2024 (UTC)

For now, I would recommend adding one to MediaWiki:Common.css and MediaWiki:Minerva.css or on the template level - if community finds it useful and usage becomes widespread we can add a global selector in the code but I'd be reluctant to add it to the core software until we see evidence it would be used.

(FWIW I'd suggest using skin-image-background-white as the selector if making this a global rule) Jon (WMF) (talk) 15:57, 11 July 2024 (UTC)

To give a concrete example: https://en.wikipedia.org/wiki/Template:Infobox_television has a rule to make the background white on https://en.wikipedia.org/wiki/The_Acolyte_(TV_series) Jon (WMF) (talk) 15:58, 11 July 2024 (UTC)

Thanks for the quick response. Sjoerddebruin (talk) 16:49, 11 July 2024 (UTC)

How to apply skin-invert-image to single image in gallery?

See above, didn't figure this out yet. The packed gallery is used at times for a mixed display of images and drawings. For example, see nl:Pjotr Iljitsj Tsjaikovski. Sjoerddebruin (talk) 16:51, 11 July 2024 (UTC)

Hi @Sjoerddebruin! Talked internally with the team, and we're pretty sure there isn't currently an easy way to apply a class to a single image in a gallery 😔 I think the best solution here would likely be something like this if we want to keep the images in a gallery

Also, know that we're working on a more general solution to address this and I hope to have more good news for you soon, but in the meantime applying a background might be the best way! SToyofuku-WMF (talk) 21:05, 15 July 2024 (UTC)

We are running into this same problem at this discussion on en.WP. There is one image in a gallery that needs to be inverted. User:SToyofuku-WMF, can you please link to the phabricator task where you are tracking the work on this "more general solution"? Thanks. Jonesey95 (talk) 13:27, 5 August 2024 (UTC)

Hi @Jonesey95! That would be https://phabricator.wikimedia.org/T370074 SToyofuku-WMF (talk) 20:42, 5 August 2024 (UTC)

Using <div> to apply `skin-invert-image` to other templates?

I was looking for a way to apply skin-invert-image class to templates that don't accept a class=..., and found out that I could wrap the template in a <div> tag and apply the class there. For example:

<div class="skin-invert-image">
    {{multiple image|align=center|total_width=540
        |image1=...
    }}
</div>

(I in fact just used that in this edit.)

Question: is this an acceptable practice, and if so can I add it to this page as a way to apply color inversion on other templates? Panangam (talk) 07:46, 19 July 2024 (UTC)

Yes this is fine! One thing to note is that you must be confident that the template only ever contains SVGs. If anything other than and SVG is inside that may not invert so well. Jdlrobson (talk) 22:48, 19 July 2024 (UTC)

Thank you for the response! Currently, I manually check each image I want to invert first to see if the inversion actually helps. I find that a lot of PNGs with transparent backgrounds benefit greatly from this as well. Panangam (talk) 10:20, 3 August 2024 (UTC)

CSS class for turning images white?

Might it be worth creating a CSS class that turns an image entirely white in dark mode (using filter: brightness(0) invert(1);)? This could be used for example on some logos with transparent backgrounds which contain colours other than black, making inversion inappropriate. Weylaway (talk) 04:49, 22 July 2024 (UTC)

If you mean inverts the image, we currently support skin-invert-image and skin-invert. For an example see the signature in en:Tupac Shakur.

If you mean turning the background white, no class for this exists right now, but we are about to work on phab:T370074 which will address most images outside of templates by adding a background by default.

In lieu of this, you can create them at the skin level (in MediaWiki:Vector-2022.css / MediaWiki:Minerva.css) or at the template level. If we see evidence that most communities are using these heavily, then we can consider upstreaming this to core.

I hope this is helpful! Jon (WMF) (talk) 17:53, 26 July 2024 (UTC)

Contrast checker

Something is wrong at least here: https://night-mode-checker.wmcloud.org/be-mobile/night.html – it is a report for ml language, not be. — putnik 18:01, 15 August 2024 (UTC)

Hi there @Putnik! Apologies for the delay in getting back to you. I'm seeing links to the be language - are you still seeing an issue, or has it been resolved? SToyofuku-WMF (talk) 18:32, 23 August 2024 (UTC)

@SToyofuku-WMF, yes, it is fine now. But could you maybe also check what is wrong with kk? It has not been updated almost for a month already. — putnik 20:00, 23 August 2024 (UTC)

@Putnik thank you for reporting this! I'll check with the team and get back to you, but in the meantime I ran the report locally and it seems like the checker might be getting stuck on https://kk.m.wikipedia.org/wiki/%D2%9A%D0%B0%D0%B7%D0%B0%D2%9B%D1%81%D1%82%D0%B0%D0%BD_%D2%9B%D0%B0%D0%B7%D0%B0%D2%9B%D1%82%D0%B0%D1%80%D1%8B%D0%BD%D1%8B%D2%A3_%D0%B5%D1%80_%D0%B5%D1%81%D1%96%D0%BC%D0%B4%D0%B5%D1%80%D1%96%D0%BD%D1%96%D2%A3_%D1%82%D1%96%D0%B7%D1%96%D0%BC%D1%96 due to its size

I'll follow up if we're able to do anything about the online report! SToyofuku-WMF (talk) 18:14, 26 August 2024 (UTC)

@Putnik we pushed a fix to exclude that page as it was taking too long to load, and the contrast checker is now running again for kkwiki - thank you again for reporting! SToyofuku-WMF (talk) 22:37, 26 August 2024 (UTC)

@SToyofuku-WMF, could you also check what is wrong with ami and pih? — putnik 14:37, 19 October 2024 (UTC)

CSS selectors for night mode only

There has to be a way to apply CSS rules in night mode only without writing all rule sets twice (which is massively unpractical and will inevitably lead to issues) as this page recommends ('Target night mode using standard media query as well as HTML classes'). Newer CSS has light-dark(), but it seems like TemplateStyles at least simply do not support it. SURJECTION _{·talk·contr·log·} 15:43, 25 August 2024 (UTC)

Well even with light-dark(), you are still specifying it twice of course :) But most importantly, light-dark is only supported by 80% of browsers. To avoid specifying multiple times, you can use already provided CSS variables. This improves consistency and makes it easier to adapt to various color schemes. Where this is not possible, you indeed have to specify twice. Then again, you also should be TESTING twice (if we are only talking testing colors). —TheDJ (Not WMF) (talk • contribs) 16:46, 25 August 2024 (UTC)

With a single light-dark(), I'd only specify a single light and dark color. Granted, it only works for colors. I don't see how CSS variables solve the underlying issue - you still need to repeat the same rules, since there are no 'if' blocks in CSS, nor can selectors use variables in any way. SURJECTION _{·talk·contr·log·} 17:24, 25 August 2024 (UTC)

And it is not that MediaWiki cannot provide this information - it does so for the Vector 2022 skin by adding a new CSS class vector-feature-night-mode-enabled (I can't find an equivalent for Minerva). SURJECTION _{·talk·contr·log·} 17:29, 25 August 2024 (UTC)

OK, I looked more into this. Apparently that Vector class is always provided in automatic mode, even if the OS doesn't request dark mode and it thus isn't enabled. So it is actually a harder problem and probably not something MediaWiki can directly solve. SURJECTION _{·talk·contr·log·} 05:58, 26 August 2024 (UTC)

That class indicates that a feature flag of the skin was enabled. Practically this class corresponds to: you get the toggle to switch between the mode. The toggles in turn determine if the class .skin-theme-clientpref-night, .skin-theme-clientpref-os or .skin-theme-clientpref-day is set when presenting you the page. —TheDJ (Not WMF) (talk • contribs) 11:12, 28 August 2024 (UTC)

@TheDJ @Surjection: I just wanted to note that it is theoretically possible to avoid the tri-state clientpref situation using some JavaScript (which is already used by the appearance selector, so it's not imposing any additional requirements.)

Browsers support (widely) a window.matchMedia method that can be used to detect whether a given media query applies to the current viewport. For example, if the appearance selector is set to "Automatic", the prefers-color-scheme status can be queried and used to set a CSS class on the documentElement (the html tag) corresponding to the color scheme that should be selected.

Something like the code below would explicitly set one of two CSS classes on the ‎<html>...‎</html> for all four possible appearance combinations:

• skin-theme-clientpref-light → light-theme
• skin-theme-clientpref-dark → dark-theme
• skin-theme-clientpref-os with prefers-color-scheme:light → light-theme
• skin-theme-clientpref-os with prefers-color-scheme:dark → dark-theme

function setDarkTheme(isDark) {
  const themes = {
    add: isDark ? "dark-theme" : "light-theme",
    remove: isDark ? "light-theme" : "dark-theme",
  };
  document.documentElement.classList.remove(themes.remove);
  document.documentElement.classList.add(themes.add);
}

function handleColorSchemeChange(evt) {
  setDarkTheme(evt.matches);
}

function selectColorScheme() {
  if (document.querySelector("html.skin-theme-clientpref-dark")) {
    setDarkTheme(true);
  } else if (document.querySelector("html.skin-theme-clientpref-light")) {
    setDarkTheme(false);
  } else if (document.querySelector("html.skin-theme-clientpref-os")) {
    const mediaQuery = window.matchMedia('(prefers-color-scheme:dark)');
    setDarkTheme(mediaQuery.matches);
    mediaQuery.addEventListener("change", handleColorSchemeChange);
  } else {
    console.log("No appearance selection detected! Defaulting to light-mode.");
    setDarkTheme(false);
  }
}
window.setTimeout(selectColorScheme, 0);

That'll ensure the ‎<html>...‎</html> tag always has only one of either dark-theme or light-theme set as a CSS class, and if the user has selected "Automatic" in the appearance selector, it'll monitor their prefers-color-scheme browser preference and update accordingly.

The appearance selector itself would need a bit of extra code to ensure that selectColorScheme() is called whenever the user's selection is changed there, along with removal of the event listener when they switch from Automatic to either of the two explicit modes, but that's the basic skin of it.

And then MediaWiki CSS authors would only have to concern themselves with two possible theme states, instead of four. So all this:

@media screen {
    html.skin-theme-clientpref-night .pane { background-color: white; color: black; }
}
@media screen and (prefers-color-scheme: dark) {
	html.skin-theme-clientpref-os .pane { background-color: black; color: white; }
}

Becomes just this:

@media screen {
    html.dark-theme .pane { background-color: black; color: white; }
}

FeRDNYC (talk) 14:56, 26 October 2024 (UTC)

(Actually, now that I look at it... I copied that CSS from the Recommendations for night mode compatibility on Wikimedia wikis page, but isn't it half-backwards? The two cases should both be applying the same styles, background-color: black; color: white;... shouldn't they? Or am I missing something?) FeRDNYC (talk) 15:07, 26 October 2024 (UTC)

Thanks for sharing your thoughts! Yes this is viable, but the downside of this approach is it requires JavaScript and would render the page in light theme before switching it to dark mode.

We are intentionally constrained with our logic for how we can run JavaScript in a render blocking fashion - we can only read a cookie and change the class on the HTML. This code is generalized currently for other use cases (other than feature flagging). Use of matchMedia is currently not supported in this location so making this work would require bespoke code or a rethink about how we serve dark mode to anons. Jdlrobson (talk) 18:24, 26 October 2024 (UTC)

JavaScript (which is already used by the appearance selector, so it's not imposing any additional requirements.)

Logged-in users can also set their mode in Special:Preferences#mw-prefsection-rendering-skin-skin-prefs, without any JavaScript, so it would impose additional requirements. —Tacsipacsi (talk) 19:25, 27 October 2024 (UTC)

url parameter

IIRC there is a url parameter to call dark (and light) mode, just like useskin=... Which is it? Geraki (talk) 17:02, 3 November 2024 (UTC)

@Geraki: ?vectornightmode=1 for desktop and minervanightmode=1 for mobile. SCP-2000 (talk) 17:44, 3 November 2024 (UTC)