Is there any way to make this script work on Wiktionary? — LissanX ( talk) 21:06, 3 October 2019 (UTC) reply

Please, please 🙏, enable this gadget in all the Wikimedia projects, especially in Wiktionary. -- Ivanics ( talk) 22:56, 15 April 2022 (UTC) reply

Would this work on Meta in global.js? Bovlb ( talk) 19:53, 13 March 2020 (UTC) reply

I will test it. - CafeGurrier66 ( talk • contribs) 16:23, 20 April 2022 (UTC) reply

I put it in common.js/.css and it worked fine. Would have liked it as a gadget there! GreenReaper ( talk) 08:26, 10 November 2022 (UTC) reply

Gadgets on meta don't work "globally", only on meta. — xaosflux ^Talk 10:32, 10 November 2022 (UTC) reply

Like at User:MusikAnimal/nightpedia. It comes with the handy install button if you have the relevant script installed... -- _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 08:51, 1 December 2020 (UTC) reply

Done. Volker E. (WMF) ( talk) 20:09, 20 April 2021 (UTC) reply

There are a few reasons to not use an almost black background colour with white text colour for dark mode. The most notable,that is making me turn it off again now and revert to a Stylus dark mode for Wikipedia ( Deep Dark), is the halation effect effect. See e.g. Why you should never use pure black for text or backgrounds Thanks, asmodai ( talk) 11:45, 25 April 2021 (UTC) reply

+1. Had to turn off the gadget after only a minute or so of use because it was quite uncomfortable to read. – Srđan ( talk) 07:07, 26 April 2021 (UTC) reply

+1. I have astigmatism, and didn't realise this was why pure-black backgrounds make (pure-)white text fuzzy for me. I like how Twitter has "Dim" and then "Lights out" modes, for example—and even in the latter the text is not pure white, but rgba(217,217,217,1.00);. There's some discussion at the village pump that "[i]nstead of filter: invert( 1 ) an invert of 0.9" might be better. I agree. Is it possible to specify this, maybe in my one's user CSS? —Hugh ( talk) 23:53, 27 April 2021 (UTC) reply

+1. I normally use Dark Mode where I could, as opposed to Light Mode, because it's easier on eyes, especially at night. Not here though, it's kind of stressful for the eyes to look at the dark (basically black) page with lots of bright text, lots of blue links, and it's overwhelming. Less contrast would definitely help. Page shouldn't be purely black, it should be somewhat dark, but not too dark, and the text shouldn't be fullbright white, it should be slightly brighter than light gray. About links - colours of the links are too saturated, I would decrease their saturation a little bit, and make them a little bit lighter. Too saturated colours and too much contrast right now. Those changes I proposed would definitely improve the Dark Mode design. I'm glad I'm not the only one that has issues with this. — Polda18 ( talk) 18:10, 31 January 2022 (UTC) reply

+1. I use dark mode in most apps but find this one hard to look at. Slightly lower contrast would be better Tenbergen ( talk) 00:41, 9 February 2022 (UTC) reply

+1. The text is way harder to read with this gadget compared to the third-party theme I was using, I guess I'll have to continue using it for a while. FDN ( talk) 14:41, 13 May 2022 (UTC) reply

• I've heard a few "don't like it"'s above, but not "how about x"'s. I think we have #000 for the background now, what is the suggestion, #111, #222, something else? — xaosflux ^Talk 18:36, 13 May 2022 (UTC) reply

+1 White on Black is not readable. Background should better be dark gray #2e3136;, font should be #f8f9fa as in the Dark theme (provided by the API) in the android app opposed to Black theme. The dark mode is one of the reasons I use the app for reading. -- Geraki ( talk) 14:39, 14 May 2022 (UTC) reply

• Ping to the larger dev team: @ Volker E. (WMF), MusikAnimal, AHollender (WMF), SD0001, and Nardog: - any feedback on this? — xaosflux ^Talk 19:11, 14 May 2022 (UTC) reply

  I personally wouldn't mind a dark gray over pure black, but then OLED screens must light the pixels and thus we do not get the same energy savings that Dark Mode was intended to provide. This gadget was originally inspired by Earth Day. I think we should offer both a pure black and a dark gray solution. This could be done as a second gadget option (that just sources different CSS, but uses the same JS), or with some effort we may be able to introduce UI elements to allow users to customize the dark theme. I'm interested in hearing other's thoughts. — MusikAnimal ^talk 20:03, 14 May 2022 (UTC) reply

  Not loving that excuse, think viewer-experience trumps minuscule power savings claims on only one display type. That being said, perhaps the primary "dark mode" should be optimized for general reading, and if someone wants a black-out-mode that could still be another option. Certainly would want to hear if I'm in the minority with that! — xaosflux ^Talk 21:22, 14 May 2022 (UTC) reply

  To be fair, I wouldn't say it's minuscule power savings, though it does depend on your display type. On OLED screens specifically (which makes up the majority of phones and tablets these days), a pure black theme can improve your battery life from a few hours to a few days. On a much larger scale, such as all visitors to our wiki, we're talking potentially a very massive reduction in environmental impact, seeing as most energy in the world is not from renewable sources. I don't think anyone is suggesting making dark mode (much less a pure black theme) the default for all users, but nonetheless the energy savings was the motivation in the beginning. I would like to hear from the others involved before changing the CSS for the existing gadget, but I see no issue with creating a second one, and perhaps swapping the two once it's refined (dark mode = dark gray, and then we have "black mode (saves energy)").

  The other problem that I completely overlooked in my first reply is that WP:Dark mode isn't truly a dark theme, rather it inverts colors with CSS. This could essentially be seen as a hack, albeit necessary. Sites like Google, Facebook, etc. have proper themes styling all elements but this is because they have full control over how content is displayed. As a publicly editable wiki, with inline styles on elements, etc., we do not have the same luxury, and this is why we resorted to inverting colors. So implementing a dark gray theme may be a bit more involved than simple tweaks to the CSS, especially with all the different skins we try to support. I'm sure it's possible, but for instance elements that have inline styles painting the colors as white will become black, and I'm not sure how we would know that's supposed to be dark gray and that it doesn't clash with any colors around it, etc. Inverting and adjusting the hue gives us a more reliably consistent look with limited need to override specific styles. The mobile site and app have what are effectively their own rendering engine that gives the developers more control, hence why a proper dark theme has been added there but is still lacking on desktop.

  I believe this all is basically why meta:Community Tech/Dark mode (#2 wish in the 2018 survey) had to be declined; the product leadership was not happy with the 'invert' solution, but on desktop (and especially 900+ wikis each with their own styles), we were left with few feasible alternatives. — MusikAnimal ^talk 22:03, 15 May 2022 (UTC) reply

  A purely black background not only is energy-efficient but looks better on OLED displays, though I guess I could use slightly darker (grayer) text for less contrast. On LCD a brighter background is indeed better, and apps like Twitter have two dark themes ("Dim" and "Lights out"), so it makes sense for us to provide a less dark dark theme, but as MusikAnimal said it all depends on whether it's feasible in CSS.

  The toggle gadget gives the <html> element the client-dark-mode class when the dark mode is on, so users can customize the dark theme and, if we could agree on what the CSS for the less dark dark theme should be, we can make it yet another gadget (though there will need to be a separate option for the toggle gadget too if we don't want FOUCs). Nardog ( talk) 22:27, 15 May 2022 (UTC) reply

+1. Right away I noticed the white text was way too "crispy" (aliased) on the pure black background and had no idea there was an actual technical explanation for it. At first I was looking to change the font to something more anti-aliased, but it became clear that was not the problem. Side note: I have dabbled in web design and out of the 20-30 websites I have made I somehow accidentally never did a pure white text on pure black background because right away within seconds it never looks right. Extremely fatiguing to try and read. I see lower in this thread it was designed for maximum power savings instead of visual pleasantness. Off to find a 3rd party theme solution. Mjǫðr ( talk) 18:31, 16 July 2022 (UTC) reply

I have done my best to implement a not-so-fantastic bodge of fixing the background colours that doesn't sear off the eyes quite so much. I suspect the reason why no-one has fixed this yet is because it's quite non-trivial to do since the gadget works by inverting the colours, you need a theme which by default is an off-white. Here it is:

Feel free to submit fixes to me as it's not all working. I'm testing on the old Vector theme. (on a related note, is global.css) really the best place for this file?

https://meta.wikimedia.org/wiki/User:Minerscale/global.css Minerscale ( talk) 10:36, 23 December 2023 (UTC) reply

@ Volker E. (WMF) and MusikAnimal: there seems to be some overlap, this is the current documentation page for the gadget - but the gadget is CSS only while this page is referencing javascript as the primary invocation. At the very least it seems that there is now going to be a fork between the gadgeted version and the userspace version - can these be reconciled? Is this documentation ready to move to Wikipedia space and stop directing users to load a userscript? — xaosflux ^Talk 15:40, 25 April 2021 (UTC) reply

This all came together pretty quickly. The userscript version has minor functional advantages over the current gadget version incl. the trigger element. I'd copy most of the documentation over and update accordingly over in the gadget page. What is the normal place for gadget documentation? – Volker E. (WMF) ( talk) 18:05, 25 April 2021 (UTC) reply

What Xaosflux added with Special:Diff/1019208333 seems fine for now (though I removed the signature). The gadget isn't really done yet. In addition to outstanding bugs, we would like to add a way to toggle it on and off, which will require an additional gadget. See the discussion at WP:VPT. Once we've got all of that figured out, I'm happy to help write documentation. — MusikAnimal ^talk 01:40, 26 April 2021 (UTC) reply

@ MusikAnimal and @ Volker E. (WMF): I updated the docs a bit per request: [1] – SD0001 ( talk) 12:45, 30 April 2021 (UTC) reply

@ Volker E. (WMF): With Vector, and "use legacy vector" selected, the left navigation area (just below the Wikipedia logo) as well as the entire bottom section (where the privacy policy, about wikipedia, disclaimers and so are contained) still have white-ish backgrounds (but the text appears to switch to colors designed to be on black/dark). If you turn off "use legacy vector" it works, but then you're stuck with a 'modern' design that doesn't utilize the full width and still has large white bars on the left/right. I'm fairly confident I installed this correctly, but was curious if this was a known issue. :) — Locke Cole • t • c 16:25, 13 May 2021 (UTC) reply

Works for me on legacy vector, both on Chrome and Firefox. @ Locke Cole Can you share more details about your platform, eg what browser/OS do you use? – SD0001 ( talk) 03:13, 16 May 2021 (UTC) reply

@ SD0001: Firefox 88.0.1 on Windows 10 20H2 19042.985. I finally had a minute to look, it seems like the body CSS is still set to a bright color (or is not being overridden), when I manually adjusted it in the Firefox developer tools, it works fine. I hardcoded it at User:Locke Cole/common.css using body { background-color: #0a0a0a; } and other than the background being dark before the rest of the interface on page load briefly, it works. — Locke Cole • t • c 06:35, 16 May 2021 (UTC) reply

FWIW, I tried it this time with the gadget and it seems to work fine now. May have been an issue with the exact build of FF I was on. Only thing I'll suggest is apparently the background color for SVG images is set to #fff, ideally it would be set to inherit to match the background of whatever element is up the chain. This is noticable with standardized templates like {{ uw-vand1}} where in dark mode the image has a white background/box. Switching to inherit seems to work in my limited testing. The exact CSS that was setting it to white was this (in load.php according to FF dev tools):

 html .image imgsrc*='svg'],
 html imgsrc*='Wiktionary-logo' {
  background-color:#fff;
  border-radius:1px
 }

I'll leave it enabled for a bit and see if I notice any other oddities. =) — Locke Cole • t • c 22:36, 12 July 2021 (UTC) reply

I don't know if I'm supposed to report this somewhere else, but I have noticed the @ symbol in Template:No spam displays as black text with this dark mode enabled, which makes it very difficult or impossible to see. (I'm using the gadget version of dark mode on Chrome.) — NormalPerson7 ( talk) 18:33, 18 July 2021 (UTC) reply

Never mind, I've just noticed that's an image and so really it's an accessibility problem with the template rather than anything wrong with dark mode. — NormalPerson7 ( talk) 18:34, 18 July 2021 (UTC) reply

When I was creating a subpage in my userspace, it was all dark in the editor. I didn't see a single character. Just to inform the author. Lightbluerain❄ ( Talk | contribs) 17:16, 24 July 2021 (UTC) reply

I'm still using Monobook and this is a horrid green-on-black scheme, with the links still blue which makes them really difficult to see, with the navigation menus and certain form elements still white. I only added the @import line to my common.css file. Hopefully I just didn't do this correctly because this is totally unusable as-is. — howcheng { chat} 07:34, 8 September 2021 (UTC) reply

Update: I had the "green-on-black" option checked. Ugh, that was horrible. — howcheng { chat}

Legends for some maps, for example the legend for the map showing European control in Africa in 1939 found here, shows the wrong colors for me when using dark theme. Not sure if this is a known issue, so I thought I'd bring it up. I'm using the gadget with Legacy Vector on Firefox. Alecnotalex ( talk) 15:34, 30 October 2021 (UTC) reply

On my user page User:Killarnee I have some text with an image as background. View it with dark theme enabled and once again with dark theme disabled, you will see dark-mode.js's change of the text's color is not really as it should be. Maybe someone could change the script so that text with an image as background or that text inside a div with eg the class no-dark or so is not changed in any way? Thanks - Killarnee ( C• T• U) 01:18, 27 November 2021 (UTC) reply

@ Killarnee I don't see anything wrong on your userpage (Chrome/Vector skin), so the issue could be limited to certain platforms. In any case, you can already opt out an element from dark mode by applying the mw-no-invert class. – SD0001 ( talk) 02:47, 29 November 2021 (UTC) reply

@ User:SD0001 thanks for your respond. To clarify, I have made a picture, on the left without and on the right with dark theme. On the right, the text above the picture is more difficult to read because it has also become white, but the background has not changed to dark. I'm using Safari 15 for macOS. - Killarnee ( C• T• U) 14:07, 29 November 2021 (UTC) reply

@ Killarnee that's not the way your userpage looks to me even in light mode. What I see is [2], the yellow background shows up at the bottom of the page (see [3]). In dark mode, it becomes this [4] without the mw-no-invert class. The effect is as expected.

It seems like a problem with the layout of the page itself. As for mw-no-invert – it prevents inversion of the contents of the div but it doesn't change the background which is inherited, so it probably is not useful here. Not sure if it's possible to create a proper way to actually opt out an element from dark mode. – SD0001 ( talk) 12:18, 1 December 2021 (UTC) reply

Oops that shouldn't be... I've fixed it now, but mediawiki is really bad on responsiveness.

But the thing with the text color still remains, which is why I also had to add the class mw-no-invert. Since you cannot display text on the image, only under the image, with [[File:x.png]], I have no idea how to fix this problem without always using the class mw-no-invert. - Killarnee ( C• T• U) 19:05, 1 December 2021 (UTC) reply

@ Killarnee Ah okay, so mw-no-invert is indeed useful here. Now the page looks fine to me in both light and dark modes. – SD0001 ( talk) 19:31, 1 December 2021 (UTC) reply

FYI

 – Pointer to relevant discussion elsewhere.

There's a discussion open at Wikipedia:Village pump (technical)#Make dark mode toggle script a gadget? about adding dark-mode toggle functionality as a gadget. – SD0001 ( talk) 05:45, 28 November 2021 (UTC) reply

This edit request to MediaWiki:Gadget-dark-mode.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

This edit request to Mediawiki:gadgets-definition has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Please apply the three edits from User:SD0001/Gadget-dark-mode.css ( edits, unified diff). This fixes issues with timeless skin:

• make logo wordmark visible
• fix displacement of #mw-site-navigation menus to bottom of the page
• remove css for manipulating the logo that doesn't seem required any longer. It was anyway applicable only if the js from User:Volker E. (WMF)/dark-mode.js is also loaded which adds .mw-no-invert, and which was now causing odd effect (a partial dark logo showing up above the light one)

Tested in Chrome and Firefox. All changes done here are in styles scoped to .skin-timeless so there won't be any regressions for other skins.

Also please modify the gadget definition to add timeless in list of skins. – SD0001 ( talk) 07:17, 28 November 2021 (UTC) reply

Added skin to the definitions. — xaosflux ^Talk 15:26, 29 November 2021 (UTC) reply

@ Xaosflux looks like you edited the skins for PageDescriptions instead. – SD0001 ( talk) 03:35, 30 November 2021 (UTC) reply

Fixed. — xaosflux ^Talk 10:40, 30 November 2021 (UTC) reply

@ SD0001: think there were some overlapping items on here, would you please add the "final" back to User:SD0001/Gadget-dark-mode.css (which is currently reset to the gadget) - ping me when done and I'll push this up. Thank you! — xaosflux ^Talk 17:24, 12 December 2021 (UTC) reply

If there aren't, just undo my last edit and ping me too :) — xaosflux ^Talk 17:24, 12 December 2021 (UTC) reply

@ Xaosflux Done (there was one edit made to the gadget since this request was opened). – SD0001 ( talk) 18:36, 12 December 2021 (UTC) reply

@ SD0001:  Done (it still complains about invalid rule @-moz-document, but that was already present - think that is deprecated in mozilla kits now). — xaosflux ^Talk 18:40, 12 December 2021 (UTC) reply

This edit request to MediaWiki:Gadget-dark-mode.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

In dark mode, the text becomes blurry and hard to read (on desktop screen), I think we should add the following code to lighten the text:

html * {
  text-shadow: 0 0 0;
}

P.T.Đ ( talk) 20:17, 17 December 2021 (UTC) reply

@ P.T.Đ: I'm not seeing this problem, which skin are you using? @ SD0001 and Volker E. (WMF): for input as well. — xaosflux ^Talk 12:10, 18 December 2021 (UTC) reply

@ Xaosflux: I use New Vector skin, Dell Precision 7520, Windows 10 and Google Chrome. If you don't see the problem, probably because you use a high resolution ppi monitor. P.T.Đ ( talk) 12:37, 18 December 2021 (UTC) reply

 Not done @ P.T.Đ: it still doesn't look "blury" to me, and I think it looks "worse" with that shadow element added (so at the very least this is now a "needs more discussion" and not a "immediate edit" item. The same font change seems to be relevant regardless of the background color too? Further discussion on this is certainly welcome below. — xaosflux ^Talk 16:38, 18 December 2021 (UTC) reply

Okay, no problem. "Blurry text" is an error caused by filter: invert(1). I've seen it on many computers, only high ppi monitors are not affected (like iPhone X). You can do some tests on other computers. P/S: text-shadow: 0 0 0 is a trick to deal with this problem. P.T.Đ ( talk) 16:55, 18 December 2021 (UTC) reply

Couple of more pings to those that have worked on this: @ MusikAnimal and Enterprisey: I don't really "object" to this, but not sure it is the right answer, everything looks OK on my desktop, but understand that other screens may act differently. — xaosflux ^Talk 17:33, 18 December 2021 (UTC) reply

I, too, am seeing worse results with the text-shadow property added. In both dark and light mode, the text normally looks very crisp. With text-shadow: 0 0 0 applied to all elements, the text becomes noticeably blurry and with a higher contrast. So it seems xaosflux and I have the opposite experience as P.T.Đ. At quick research I can't seem to find any information on this specific "error" caused by filter: invert(1). I am not very fond of applying the proposed change unless it can be shown it fixes a documented issue, and that that issue effects the majority of our traffic. — MusikAnimal ^talk 18:23, 18 December 2021 (UTC) reply

It's so confusing, I don't even know how to explain it. I think the gadget doesn't need to change anything, and I still use text-shadow to fix this weird "error" (on another wiki, I'm not active here). P.T.Đ ( talk) 19:01, 18 December 2021 (UTC) reply

@ P.T.Đ: if it is something that is always helpful for you, you could just put it in User:P.T.Đ/common.css (assuming that it doesn't make "light mode" worse for you that is). Unless we get more info or reports from others, I don't think this should be in there for now. — xaosflux ^Talk 19:09, 18 December 2021 (UTC) reply

Well, some Vietnamese Wikipedia users have reported to me about this problem, see the discussion and some comments:

• "Tôi cảm thấy chữ bị nhòe, trông rất hại mắt." (I feel the text is blurred, it looks very bad to the eyes.)
• "Ở phiên bản desktop, chữ vẫn bị nhòe, chắc chỉ thỉnh thoảng mới dùng thôi." (In the desktop view, the text is still blurred, maybe only used occasionally.)

Then, I fixed vi:MediaWiki:Gadget-dark-mode.css. P.T.Đ ( talk) 19:17, 18 December 2021 (UTC) reply

I can reproduce the issue on a Lenovo IdeaPad laptop. Not sure if I should call it "blurry", but it just looks really bad. Adding text-shadow: 0 0 0 makes it better. However, on my mac's retina display there's no issue at all, and adding text-shadow makes text bolder. https://stackoverflow.com/a/39811009/9306016 looks like some documentation for the issue. Overall, I think I'm in favour of the change because its impact on high-end screens seems minute and not noticeable once you get used to it.

It's futile to illustrate the problem using screenshots, because the screenshots look perfectly fine when viewed on a screen that doesn't experience the issue. – SD0001 ( talk) 05:05, 19 December 2021 (UTC) reply

If bold white text is annoying on retina screens (and other high ppi screens), we can increase the brightness of the background a bit. This makes for a better experience. See a related post: Why You Should Never Use Pure Black for Text or Backgrounds. P.T.Đ ( talk) 06:08, 19 December 2021 (UTC) reply

Maybe we should figure out WHY that works for people. It sounds a bit like a filter bug on certain setups which don't have proper text antialiasing, esp. on non-retina screens ? — TheDJ ( talk • contribs) 11:55, 19 December 2021 (UTC) reply

Right. So what PTD is seeing, is likely because ClearType on Windows sucks (esp. with certain fonts on non-retina screens) and setting text shadow disables cleartype. Does anyone know of a method to detect windows using CSS ? Or maybe we can use a media query and only set this property on screens which are non-retina and it will be good enough for the biggest set of users ? — TheDJ ( talk • contribs) 13:19, 19 December 2021 (UTC) reply

According to this it doesn't look possible to detect OS using CSS. But regardless of that, it seems better to use resolution media query to target based on DPI/PPI? – SD0001 ( talk) 17:47, 19 December 2021 (UTC) reply

@ SD0001 and MusikAnimal: What if the toggle script added a class to <html> if the dark mode is on? That would allow users to tweak the dark CSS to their liking, notwithstanding the delay between the page load and script execution. Nardog ( talk) 12:28, 23 December 2021 (UTC) reply

Actually I had already sandboxed that change in the toggle script, although for different intentions – I've now requested edit here.
As for this issue, I think it's worth adding a resolution-specific css rule in the gadget itself because this is clearly not a one-user issue. @ TheDJ what would you think is a suitable value for max-resolution? – SD0001 ( talk) 14:23, 23 December 2021 (UTC) reply

Using desktop view on my ICONE IRON PRO, an STB device with Android 7.0, I have the same issue and I have to highlight the text with the controller's mouse, so that's a large support. - CafeGurrier66 ( talk • contribs) 16:25, 20 April 2022 (UTC) reply

This edit request to MediaWiki:Gadget-dark-mode.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Please sync the changes from User:SD0001/Gadget-dark-mode.css ( diff). The following changes have been done:

• remove popups style which is only causing a stray gradient patch to show up where it doesn't belong, as shown in https://ibb.co/HCr4WfT
• fix background colors in diffs. Currently the blue/yellow background for added/removed text is almost invisible
• remove un-inversion of logo in vector skin that depends on class added by User:Volker E. (WMF)/dark-mode.js script which is not part of the gadget
• fix display of mobile notifications at the bottom of the screen (the ones like "edit saved successfully") - currently they display black-on-black, which is unreadable
• don't create white background around emojis generated by {{ emoji}}

– 
SD0001 (
talk) 12:21, 24 December 2021 (UTC)
reply

 Done — xaosflux ^Talk 16:17, 25 December 2021 (UTC) reply

I'm pondering how to fix Template:Legend. feedback welcome on its talkpage: Template_talk:Legend#Dark_mode_compatibility — TheDJ ( talk • contribs) 10:19, 6 January 2022 (UTC) reply

There is another issue on pages discussing specific colours. There are many of these out there, but let us start with Color term These get their colours hue adjusted as well. That might not be desirable..? I was thinking that maybe with an "mw-no-hue-rotation" class or something, we could undo that ? — TheDJ ( talk • contribs) 10:23, 6 January 2022 (UTC) reply

FYI, this is impossible to fix, because of the technique used for this dark mode gadget. The use of filters is irreversible, the combination with hue offsetting causes loss of information when trying to reverse. This is one of the reasons why a 'true' dark mode is preferable over this current implementation, and part of why they did not roll this out everywhere I think. — TheDJ ( talk • contribs) 14:32, 3 February 2022 (UTC) reply

This edit request to MediaWiki:Gadget-dark-mode.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Between line 37 and line 38 please add: html ogvjs, to fix the color of the non-native ogvjs playback on Safari. — TheDJ ( talk • contribs) 14:09, 8 January 2022 (UTC) reply

 Done — xaosflux ^Talk 14:35, 10 January 2022 (UTC) reply

I found that Minerva sets a specific theme-color using the head. In iOS this overrides the colorscheme of the addressbar and the topbar. Unfortunately we cannot override this with CSS to a dark mode, so it doesn't work icw the darkmode gadget. I also noticed that Minerva seems to ONLY set this for article pages. If you open a special page, it doesn't specify a theme-color and iOS will default you to the color of the body background.

We can probably modify the theme-color meta element in the toggle gadget to take dark mode into account. — TheDJ ( talk • contribs) 00:37, 9 January 2022 (UTC) reply

Edit request to 'fix' this with JS is now here — TheDJ ( talk • contribs) 15:19, 3 February 2022 (UTC) reply

Hi there, Special thanks to users who created and developed this gadget! Today, I exported the gadget to ckbwiki and I noticed two problems while using it. First, anything fixed on the pages will not remain fixed, but they will move as the page moves. For example, see those buttons on Template:Skip to top and bottom in Dark mode. Second, the text of SVG files/images written in black will not change to white (See commons:File:بە خێر بێیت بۆ ویکیپیدیا.svg) when we switch Dark mode on while the Wikipedia logo text (you can see on the top-right corner on ckb:دەستپێک) will be changed and turned white. And finally, I wanna say that the Dark mode gadget is totally black and (in my opinion) this is not good in these days. I personally prefer blue or gray shades or something like these. Thanks again! ⇒ Aram Talk 21:59, 19 January 2022 (UTC) reply

These are all downsides of the current technique of filters, used by this gadget. The SVG issue might be addressable if we set a custom background color for all images, and assume that transparency, isn't very important... Though I'm sure there are counter examples for that... — TheDJ ( talk • contribs) 14:38, 3 February 2022 (UTC) reply

The hue-rotate( 180deg ); part of the filter:invert code messes up the colours on at least one image. The colours on the album cover for the Late Night Tales: Röyksopp page is paler than original. See this image for a comparison between dark mode, light mode and dark mode without hue-rotate -- havarhen | Talk 09:30, 8 February 2022 (UTC) reply

Yes this is a known downside to this system of using filters. — TheDJ ( talk • contribs) 09:39, 10 February 2022 (UTC) reply

Thanks for taking a stab at dark mode for mediawikis. It would be awesome if this worked out!

I tried to edit Battle_of_Sekigahara#Kokudaka_of_daimyō and some of the markup at the top of the section was not visible unless I select it. Tenbergen ( talk) 01:45, 9 February 2022 (UTC) reply

Battle_of_Sekigahara#Kokudaka_of_daimyō is a long table that has images in it. The header bar stays in place as one scrolls through the long table (not mediawiki standard, must be some wikipedia thing). With dark mode on, the images slide across the stopped header. Tenbergen ( talk) 01:45, 9 February 2022 (UTC) reply

@ Volker E. (WMF) and MusikAnimal: this gadget worked in kkwiki for around only 15-20 seconds then stopped working. I switched between modes several times then stopped. I did nothing else. How to fix this issue? -- Arystanbek ( talk) 03:09, 11 February 2022 (UTC) reply

@ Arystanbek You don't appear to have a gadget definition for "dark-mode-toggle-pagestyles". Instructions are at Wikipedia:Dark mode (gadget). I have global edit interface rights, so I can help set it up for you, if you'd like. — MusikAnimal ^talk 19:15, 13 February 2022 (UTC) reply

@ MusikAnimal yes, It would be nice if you could help. -- Arystanbek ( talk) 07:07, 14 February 2022 (UTC) reply

@ Arystanbek You should be all set now. Let us know if there are any problems. Best, — MusikAnimal ^talk 23:16, 14 February 2022 (UTC) reply

@ MusikAnimal I'm so grateful for your help! -- Arystanbek ( talk) 23:28, 14 February 2022 (UTC) reply

Hi, I observed certain issues with the dark mode gadget. I pointed them out at Response of visual elements on using Dark mode (gadget). Any interested editor is invited to visit there. Thanks! --- CX Zoom(^he/_him) ( ^{let's talk}| _contribs) 16:03, 27 February 2022 (UTC) reply

So currently we set white as the background on all svg images and thumbnails, but most inline images keep their original background, incl pngs with transparency on their file page like: File:Epic_Records_1970s.png.

I don't really see why we do not set the white background for all images.. Does anyone know if there is a good reason ? — TheDJ ( talk • contribs) 10:11, 8 March 2022 (UTC) reply

Possibly, because we DO want the invert to apply to inline math images, and those should then thus NOT have a white background ? — TheDJ ( talk • contribs) 10:13, 8 March 2022 (UTC) reply

Hi! So this is a very minor issue, but in skins such as Vector2022 and Timeless, there is a user menu with icons designed to exemplify the link. For example, the talk link is a speech-bubble with a smiley face. However, I noticed that the dark mode gadget does not have a corresponding icon. Is there a way to add an icon such as a light/dark sun/moon? Thanks. — 3PPYB6 — TALK — CONTRIBS — 02:11, 5 April 2022 (UTC) reply

@ Volker E. (WMF), Volker E., SD0001—courtesy ping as you created this gadget. — 3PPYB6 — TALK — CONTRIBS — 02:13, 5 April 2022 (UTC) reply

See MediaWiki talk:Gadget-dark-mode-toggle.js#Portlet icon. Nardog ( talk) 02:15, 5 April 2022 (UTC) reply

@ Nardog— Tested it on my test account and it works; thanks! — 3PPYB6 — TALK — CONTRIBS — 02:21, 5 April 2022 (UTC) reply

@ Nardog I think we should make it a part of the gadget itself. – SD0001 ( talk) 07:33, 5 April 2022 (UTC) reply

The dark mode is too extreme in my opinion, the blue text doesn't really look very good on a black background. Can I suggest to any of the developers reading this to make the dark mode a dark grey with white text and lighter grey for article links, similar to the design of Wiki Wand? Though something which places the article titles on a black background with white text I think would be a good addition too, something to embolden the article names.The black is too extreme for the article backgrounds though. Perhaps an option to have the article title and side panels with black and white and the articles white and normal that would be useful rather than the whole thing black and white. ♦ Dr. Blofeld 16:36, 4 May 2022 (UTC) reply

It appears that applying any CSS filter to html or body, even an empty one like body { filter: hue-rotate(); }, causes position:fixed elements such as the toast-type notification after submitting an edit or the top bar of the "timeless" skin to become unfixed and behave as if they were position:absolute.

This is not the fault of the CSS code, but an apparent bug in the browser. Just noting it here for anyone unaware, since it appears no one has mentioned it yet. Anerisys ( talk) 22:42, 15 May 2022 (UTC) reply

Anerisys, I seem to have run into the same thing. mw.loader.using(['oojs-ui-core','oojs-ui-windows']).then(function(){OO.ui.alert('test')}); doesn't work right either. — Alexis Jazz ( talk or ping me) 05:05, 28 July 2022 (UTC) reply

@ Anerisys is there a Mozilla bug open on this for reference? — xaosflux ^Talk 10:33, 28 July 2022 (UTC) reply

Xaosflux, [5], [6]. The edit request below seems related? — Alexis Jazz ( talk or ping me) 12:33, 28 July 2022 (UTC) reply

This edit request to MediaWiki:Gadget-dark-mode.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Hi! In https://bugzilla.mozilla.org/show_bug.cgi?id=1423746 I've fixed the bug that caused the @-moz-document rule to be needed. However, with the fix that rule causes the unintended effect of having a white background on the left pane, see https://bugzilla.mozilla.org/show_bug.cgi?id=1770767.

Instead, in order for this to work on all browsers, including old Firefox versions without the fix, you can change that rule to be:

:root, body {
  /* Specify the background on both root and body to workaround
   * https://bugzilla.mozilla.org/show_bug.cgi?id=1423746 */
  background-color: white;
}

This works because the Firefox bug meant that the root background wasn't filtered (because it was "behind" the filtered area).

However by specifying it both in the root element and the body element, you can get Firefox to filter the body background as well.

This shouldn't have any other side effects so in practice that rule can be in all browsers.

Thanks,

-- Emilio Emiliocobosalvarez ( talk) 17:41, 23 May 2022 (UTC) reply

Not sure what I'm missing here, I'm loading the page in FF 100.0.2 64bit, and not seeing the "white bar" problem you've described. As far as adding special extra sytling for "root, body" I haven't heard any other browsers reporting issues requiring this? — xaosflux ^Talk 00:43, 30 May 2022 (UTC) reply

The problem only shows in Nightly, because the issues was only fixed 16 days ago it seems. I can confirm that it happens for classic Vector in that version. I'd still wrap this inside the moz-document media query, as the background of the skins is not all white (that was just a hack applied here) and changing all the skins to set both root and body seems a bit problematic. — TheDJ ( talk • contribs) 10:54, 30 May 2022 (UTC) reply

 Not done for now: Emiliocobosalvarez / Volker E. (WMF) Please see TheDJ's comment. Izno ( talk) 19:41, 3 June 2022 (UTC) reply

Ok, seems reasonable to do that only for Firefox for now, I guess eventually we should be able to remove this completely. So something like this?

@-moz-document url-prefix() {
  :root, body {
    /* Specify the background on both root and body to workaround
     * https://bugzilla.mozilla.org/show_bug.cgi?id=1423746 */
    background-color: white;
  }
}

Emiliocobosalvarez ( talk) 16:13, 5 June 2022 (UTC) reply

TheDJ? Izno ( talk) 08:28, 10 June 2022 (UTC) reply

I concur. — TheDJ ( talk • contribs) 11:20, 10 June 2022 (UTC) reply

BTW, thank you for the effort ! — TheDJ ( talk • contribs) 11:22, 10 June 2022 (UTC) reply

 Done (used #fff instead of "white", as this style is used in the rest of the script). — xaosflux ^Talk 12:35, 10 June 2022 (UTC) reply

On my end (also Firefox), the bottom and left panels now look white ( image). I'm not entirely familiar with what the issue was here, but what was the reason for changing the background colour from #000 to #fff? ArcticSeeress ( talk) 18:03, 10 June 2022 (UTC) reply

 Undone @ ArcticSeeress: I'm undoing the last change, please check in 5 mins. @ Emiliocobosalvarez: do you have any comment on this? — xaosflux ^Talk 18:07, 10 June 2022 (UTC) reply

That fixed the issue. Thanks! ArcticSeeress ( talk) 18:14, 10 June 2022 (UTC) reply

 Not done this needs more testing based on the error report above. — xaosflux ^Talk 11:11, 11 June 2022 (UTC) reply

@ ArcticSeeress Oh, I can repro that on tall pages (like this). The issue is that with the current Wikimedia styles the root/html elements don't take the height of the full page, which cause this. Ok, let me try to find a more clever solution to not break versions of Firefox <= 101:

@ TheDJ this should do:

/**
:: * Versions of Firefox <= 101 have a bug where filter on the root element
:: * doesn't apply to the canvas background. So force the canvas background to
:: * black in those versions of Firefox. We abuse the fact that Firefox 102 is
:: * the first version of Firefox shipping `overflow-clip-margin` to detect this.
:: *
:: * See: https://bugzil.la/1769512
:: *      https://bugzil.la/1423746
:: */
::@-moz-document url-prefix() {
::  @supports not (overflow-clip-margin: 1px) {
::    body {
::      background: #000;
::    }
::  }
::}

Emiliocobosalvarez ( talk) 10:00, 21 June 2022 (UTC) reply

Ah, sorry meant to ping @ Xaosflux above... And apparently I managed to fail at syntax highlighting CSS in Wikimedia three times in a row which seems amazing, sorry :/

Anyways, hopefully the code block above is understandable, and it should keep current behavior for old versions of Firefox, and behave as all other browsers for newer versions of Firefox, which is the desired outcome. Emiliocobosalvarez ( talk) 11:05, 21 June 2022 (UTC) reply

I think this patch is causing the current issue with the overflow area, per the image posted above by ArcticSeeress. The dark mode gadget applies an invert filter to the root HTML node, and with this setting the background to black, it results in the white overflow area. I think the background: #000 should actually be background: #fff. I've applied this change in my vector.css override and the white overflow area returned to black as expected. Sideswipe9th ( talk) 18:57, 30 June 2022 (UTC) reply

I just noticed this today and came here to see what was going on. Someone please fix this ASAP. Tad Lincoln ( talk) 21:53, 1 July 2022 (UTC) reply

Which was the original patch. Izno ( talk) 17:22, 5 July 2022 (UTC) reply

I may not have waited long enough, but it doesn't seem that the last snippet above alone fixes the current firefox issue. — xaosflux ^Talk 20:42, 5 July 2022 (UTC) reply

From my own brief testing on Firefox 102.0, the last patch from Emilio is what is causing the issue. Unfortunately I don't have an easy way to test Firefox versions 101 or earlier to confirm whether or not the fix for it in versions >= 102 also causes it to happen in versions <= 101 as mentioned by ArcticSeeress. Sideswipe9th ( talk) 20:50, 5 July 2022 (UTC) reply

We are running the codebase from January still, that first patch was reverted after it caused new problems. — xaosflux ^Talk 21:35, 5 July 2022 (UTC) reply

Got a few minutes there to spin up a VM with Firefox Portable version 101 and 102. The following snippet resolves the white border issue in both version 101 and 102. The issue with the snippet from 21 June was that both the logic of the @supports selector and the background: were backwards. This snippet uses the @supports selector to determine if the user is using Firefox version >= 102, and then gives the body the proper background colour for the inverter to work. For any versions <= 101, the old behaviour is maintained as whatever background value is set via the skin elsewhere on the body tag is used.

 @-moz-document url-prefix() {   @supports (overflow-clip-margin: 1px) {     body {       background: #fff;     }   } }

Sideswipe9th ( talk) 23:00, 5 July 2022 (UTC) reply

The mw-css validator is complaining about syntax on that; seems to not like the @supports being nested in there. — xaosflux ^Talk 23:32, 5 July 2022 (UTC) reply

Interesting. Sadly I don't know how that tool works behind the scenes to assist with that. Sideswipe9th ( talk) 23:40, 5 July 2022 (UTC) reply

@ Sideswipe9th you can test these at User:Sideswipe9th/common.css. — xaosflux ^Talk 00:41, 6 July 2022 (UTC) reply

@ Xaosflux: Oh. I've got it applied already at User:Sideswipe9th/vector.css which is how I tested it for both of the Firefox versions I mentioned earlier. I'll add it to the common.css now and test it again with the other skins now. Sideswipe9th ( talk) 00:45, 6 July 2022 (UTC) reply

@ Sideswipe9th see the "unexpected token" errors in User:Sideswipe9th/darksandbox.css. — xaosflux ^Talk 00:59, 6 July 2022 (UTC) reply

(right at the end) — xaosflux ^Talk 00:59, 6 July 2022 (UTC) reply

@ Xaosflux: Yeah I see that. It's purely the fault of @-moz-document, because that's a non-standard Gecko only CSS extension. Looks like the parser is giving up after that, so isn't interpreting any of the open curly brackets. If there's only a single @-moz-document it doesn't complain about the unexpected tokens. Sideswipe9th ( talk) 01:06, 6 July 2022 (UTC) reply

Tested it now with that line in my common.css, with every skin, on Firefox versions 101 and 102. Dark mode is working fine in both versions on all skins. The code editor at common.css is complaining about an unknown rule @-moz-document regardless of whether or not the remainder of the css is present. From a quick Google search, it's because @-moz-document is a Gecko only CSS extension. Testing on Chrome shows it to have no effect, presumably because Chrome is ignoring the rule entirely. Sideswipe9th ( talk) 00:57, 6 July 2022 (UTC) reply

 Done @ Sideswipe9th: thanks for the note, I've added that to the main - any intadmin should revert if new breaking issues are introduced. — xaosflux ^Talk 01:12, 6 July 2022 (UTC) reply

In some desktops, I get extreme "lag" while using this. Every single action, from scrolling down while reading a page to any and all formatting keyboard shortcuts while writing articles, are infuriatingly slow and unresponsive. Disabling this dark mode fixes the issue instantly. Any ideas on what could be causing this? Both of my machines are using Firefox, only one of them has this issue. YuriNikolai ( talk) 18:02, 14 July 2022 (UTC) reply

This gadget uses a graphic filter to achieve this effect. If you are experiencing a huge lag, this means that either no hardware acceleration is being used for this filter by your graphics card, or that your computer is particularly old. — TheDJ ( talk • contribs) 18:14, 14 July 2022 (UTC) reply

Thanks for the quick reply! I'll stop using the gadget for now until my machine situation has improved. Suggesting adding a notice of this restriction to the project page, as for example all of my local libraries's computers fall under this limitation and are also unable to have this gadget on without great slowness. YuriNikolai ( talk) 16:30, 19 July 2022 (UTC) reply

Hello @ YuriNikolai,

I have the same problem as you and following TheDJ indication, I tried to modify a few settings and found one which solved that problem.

First, keep in mind that changing the default parameter could make Firefox unstable, I discovered Wikipedia’s dark mode twenty minutes ago and the solution just now, so I did not have the time to experience any stability or performance issues.

The solution in my case was to go on the “about:config” page and set gfx.webrender.enabled to true.

If you can not start Firefox after this change, I suppose that you can override your modification by creating a file named user.js in your Firefox’s folder with the following line in it: user_pref("gfx.webrender.enabled", false);. -- Bischnu ( talk) 19:50, 2 October 2022 (UTC) reply

I encountered this same problem running Firefox on Void Linux, and toggling gfx.webrender.enabled to true fixed it. Ensignmorituri ( talk) 09:56, 28 December 2022 (UTC) reply

If you can't get this solution working (my old laptop doesn't seem to like it), using the Dark Reader extension as an alternative works pretty well for me without any lag. Littlebigbug ( talk) 04:21, 3 December 2023 (UTC) reply

Some utilities change the colours of one's monitor; at the extreme, they put it in a near-redscale mode. I have enabled the Dark Mode gadget, installed Redshift, and run (at the Linux command line) redshift -O 1000 (cancel with redshift -x).

It seems to work pretty well. The colours that ought to be distinct are. The blue text of the wikilinks is a bit dark, especially at low viewing angles; it's hard to read my topbar (the bit that starts with a link to my userpage, contains the Dark Mode toggle, and ends with a logout link). Alas, screenshots don't show it, and YMMV on the viewing angle.

This meets the astronomy usecase mentioned on Phab ( T26070), as well as the more common usecases for reddening your display. Since redscale is isomorphic to greyscale, and greyscale is colourblindness-proof, good accessibility and usability with redscale need not have seperate maintenance overheads. HLHJ ( talk) 19:55, 31 July 2022 (UTC) reply

In the new reply boxes on Talk pages, like the one I typed this into, the cursor sometimes flashes black on black. For instance, when there is no text in the message-body box; also on other occasions I have yet to define. It's not very visible . HLHJ ( talk) 01:07, 1 August 2022 (UTC) reply

Cannot reproduce. Which OS and browser? – SD0001 ( talk) 10:05, 1 August 2022 (UTC) reply

Debian stable and its Firefox LTS; very vanilla. It happened in this textbox too. HLHJ ( talk) 14:01, 3 August 2022 (UTC) reply

Hello, I have a lot of experience writing Javascript and I'm wondering if it would be worthwhile to place an image into a Canvas and programatically determine what sort of background would be best (possibly even generating a background layer). Is there any interest in this? Some images that have transparency in them but have a border or are in the shape of a circle could benefit greatly from this, for example, university seals. Some images fit no standard shape and are dark colored--the best option might be to create a sort of light colored outline around these or just invert the colors if there's no tint (ie. Vizio or Apple logo). And still others with only colors light enough need no background at all (ie. Nestlé or Tesla logo).

I just wanted to check if you would find value in a JS addon like this to this theme. If so, I'm more than willing to write one, and already have something written today (but needs some work). Dani210 ( talk) 15:38, 2 August 2022 (UTC) reply

JFYI: Wiktionary logo hack in MediaWiki:Gadget-dark-mode.css#L-149 does not work for all wikis who would use the gadget, since sometimes Wiktionary logo can look like and not like this . I think hacks like these should be moved somewhere further down in the CSS, so that re-users don’t have to comment out lines in the middle of the file for their wikis, like I had to do. stjn 11:32, 28 August 2022 (UTC) reply

The dark mode option in the dropdown only shows up when at the top of the page. After scrolling down, the dropdown within the sticky header doesn't have it :( – SD0001 ( talk) 17:04, 4 October 2022 (UTC) reply

@ SD0001: Patch. Will request an edit if it looks good to you. I wish the skin simply used the same element for the sticky header though... Nardog ( talk) 08:52, 15 October 2022 (UTC) reply

@ Nardog: Thanks! Looks good to me. – SD0001 ( talk) 10:31, 15 October 2022 (UTC) reply

Something has changed (not again!) in vector-2022. Now the icon shows up only in the sticky header. – SD0001 ( talk) 06:44, 18 February 2023 (UTC) reply

@ SD0001: Patch. Can you try it on testwiki? Nardog ( talk) 22:24, 18 February 2023 (UTC) reply

Yes, it's working fine after deploying on testwiki. Thanks! – SD0001 ( talk) 05:37, 19 February 2023 (UTC) reply

This edit request to Mediawiki:gadget-dark-mode-toggle.js has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Please sync from User:Nardog/dark-mode-toggle.js. – SD0001 ( talk) 05:37, 19 February 2023 (UTC) reply

 Done @ SD0001 and Nardog: this has been applied. — xaosflux ^Talk 15:45, 23 February 2023 (UTC) reply

Please sync from here. This fixes the duplicate icon or toggle in Vector 2022 reported at WP:VPT#Dark mode icon. Appears to be working on testwiki (cc SD0001). Nardog ( talk) 19:41, 25 April 2023 (UTC) reply

 Done Izno ( talk) 19:51, 25 April 2023 (UTC) reply

Something broke *again* in vector-2022. No icon in sticky header + when you toggle the mode, the label text appears twice on top of one another. – SD0001 ( talk) 18:27, 15 June 2023 (UTC) reply

This edit request to MediaWiki:Gadget-dark-mode-toggle-pagestyles.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Hotfix. Looks like icons don't use pseudo-elements anymore (the text in the icon element strikes me as a bug). The rules added here were removed for now because they no longer have any effect (the addition of the toggle as a whole fails when logged out). Nardog ( talk) 19:03, 15 June 2023 (UTC) reply

@ Nardog Thanks for jumping right on. Deployed on testwiki. Icon is visible now, but the double label still appears on toggle. – SD0001 ( talk) 19:48, 15 June 2023 (UTC) reply

Actually, the double label bug now occurs only when debug=1 is in use. I think we can ignore it. – SD0001 ( talk) 20:26, 15 June 2023 (UTC) reply

 Done For the improvement. Izno ( talk) 20:12, 15 June 2023 (UTC) reply

My bad, the patch hid the icon in Minerva. Please sync from here. Nardog ( talk) 00:18, 17 June 2023 (UTC) reply

 Done Izno ( talk) 00:30, 17 June 2023 (UTC) reply

Currently, when you turn on dark mode in one tab, any other open wikipedia tabs will continue to be in light mode (and vice-versa). We can fix this by using storage events. I see we're currently saving the state only to sessionStorage (not persisted across tabs) – we'd need to use localStorage instead. – SD0001 ( talk) 07:52, 22 October 2022 (UTC) reply

Might as well go for https://developer.mozilla.org/en-US/docs/Web/API/BroadcastChannel I think ? Not supported by some older browsers, but widely enough in my opinion for something that is pretty minor and seems like the more modern way to do it. And localstorage has some downsides (filled up quite often on wmf sites with cached resources, doesn't work in privacy mode and lots of ppl have localstorage disabled for privacy reasons using extensions. — TheDJ ( talk • contribs) 09:46, 22 October 2022 (UTC) reply

This edit request to Mediawiki:gadget-dark-mode-toggle.js has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Please sync with User:SD0001/dark-mode-toggle2.js ( compare). This adds the above feature using the BroadcastChannel API. Also includes some code cleanup and optimisation done by Nardog. – SD0001 ( talk) 15:48, 2 November 2022 (UTC) reply

SD0001 -  Done. ~Oshwah~ ^{(talk) (contribs)} 03:17, 4 November 2022 (UTC) reply

With dark mode enabled, images are shown with inverted colors on their details page when using the mobile interface en.m.wikipedia.org .

For example, https://en.m.wikipedia.org/wiki/Albert_Einstein#/media/File%3AEinstein_1921_by_F_Schmutzer_-_restoration.jpg is displayed like this on all my computers (Android, Windows) and browsers (Chrome, Firefox): https://i.imgur.com/Q7pTnaE.jpg Abdull ( talk) 15:13, 22 October 2022 (UTC) reply

This is because those elements provide their own css filter which overrides the settings of this gadget.

This edit request to MediaWiki:Gadget-dark-mode.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Please add below line 50 of MediaWiki:Gadget-dark-mode.css (html .mw-mmv-pre-image,) the line: html .media-viewer .image img Then below line 77 (html .cx-callout, add html .overlay.media-viewer, to fix the above detailed issues. — TheDJ ( talk • contribs) 22:13, 22 October 2022 (UTC) reply

TheDJ -  Done. ~Oshwah~ ^{(talk) (contribs)} 13:34, 31 October 2022 (UTC) reply

This edit request to MediaWiki:Gadget-dark-mode.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Can someone make this forward / backwards compatible edit in preparation for enabling changes to how media is rendered?

/info/en/?search=Special:ComparePages?page1=MediaWiki%3AGadget-dark-mode.css&rev1=&page2=User%3AArlolra%2Fsandbox%2FMediaWiki%3AGadget-dark-mode.css&rev2=&action=&unhide=&diffmode=source

There's some explanation of the reason for this change at mw:Parsoid/Parser_Unification/Media_structure/FAQ

Thanks, Arlolra ( talk) 22:37, 28 October 2022 (UTC) reply

Just a note that the above topic is requesting to add html .media-viewer .image img which would need an equivalent html .media-viewer .mw-file-description img in this patch. Arlolra ( talk) 16:29, 29 October 2022 (UTC) reply

Arlolra -  Done. I also implemented the equivalent code that you noted above as well. ~Oshwah~ ^{(talk) (contribs)} 13:35, 31 October 2022 (UTC) reply

This edit request to Mediawiki:gadget-dark-mode.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

When searching on mobile thumbnails look odd (reported by @ Ladsgroup on https://phabricator.wikimedia.org/T26070#8401685)

Please add `html .list-thumb,` selector above `html .ext-related-articles-card-list .ext-related-articles-card-thumb` to fix! Jdlrobson ( talk) 23:09, 18 November 2022 (UTC) reply

This is a hard problem to deal with, because I'm sure some of the page images are text that you would not be able to see on a dark background without the current flip. Izno ( talk) 02:29, 22 November 2022 (UTC) reply

But maybe @ TheDJ above's comment indicates that's not a problem here either? Izno ( talk) 02:30, 22 November 2022 (UTC) reply

This is already being done for thumbnails in vector-2022 search results, mobile "related articles" links and should be done here as well. If page image is text, they would presumably be having a white background local to the image. Even if not, it's a smaller problem than every page image being flipped, resulting in ghastly pics of faces. – SD0001 ( talk) 05:59, 22 November 2022 (UTC) reply

•  Done revert if it breaks anything. — xaosflux ^Talk 13:16, 4 December 2022 (UTC) reply

On the mobile website, the WP logo at the bottom of the page is black, and thus illegible in dark mode. A second unrelated problem affects both the mobile and desktop layouts on android Firefox. When dark mode is enabled the links at the bottom of the page don't work which means I have to disable dark mode to switch between them. This doesn't affect Chrome. -- Nickps ( talk) 13:38, 21 November 2022 (UTC) reply

This , as you can see, appears inverted in Dark Mode. Is this deliberate? סשס Grimmchild. He/him, probably 08:43, 6 December 2022 (UTC) reply

Emojis created using {{ emoji}} template don't get inverted. Ones inserted directly via smart keyboards (or by copy-paste) will get inverted. As long a dark mode is being achieved by inverting colours, there's no solution for this as far as I know. – SD0001 ( talk) 06:43, 14 December 2022 (UTC) reply

Had to use the Noir extension instead. Image previews look horribly dull and if you click on them they load in the full color in the full-screen preview. Not sure why this issue is happening but I just wanted to post this to keep the developers aware. The same issue happens with the Chromium engine in macOS so I know that it's not solely a WebKit issue. Evieliam ( talk) 21:27, 9 January 2023 (UTC) reply

It happens because it is a double filter, and you cannot undo the color shift. Its one of the many known problems to using the method of this gadget to provide a dark mode. — TheDJ ( talk • contribs) 09:50, 21 February 2023 (UTC) reply

For some reason, when I DISABLE the gadget, an unclickable "light mode" menu item appears at the top (Vector 2010 UI), but when I ENABLE it, it disappears. I have to manually go into preferences and disable the Core styling option under Utility modules. This really shouldn't be happening, rather obviously. Nathan67003 ( talk) 17:10, 18 January 2023 (UTC) reply

As that option says, Use the dark mode toggle gadget above to control this feature. Nardog ( talk) 17:16, 18 January 2023 (UTC) reply

This edit request to MediaWiki:Gadget-dark-mode.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Problem

1. The musical score (<score>, see H:SCORE) image have transparent background instead of white, so it renders black-on-black in the dark mode.
2. Egyptian hieroglyphs (<hiero>, see Help:Hiero) image for the same reason renders black-on-dark gray

Examples

Proposed solution

I propose adding the following selectors for {filter: none;} in /* Reset overrides */ (line 66):

,
html .mw-ext-score img,
html .mw-hiero-table img

This way music scores and hieroglyphs are inverted in dark mode and render in readable white-on-black M5 ( talk) 20:13, 10 March 2023 (UTC) reply

Tested in local, and seems to work, so  Done, thanks! Writ Keeper  ⚇ ♔ 14:49, 14 March 2023 (UTC) reply

After I enabled the dark mode gadget, when I opened Wikipedia in a mobile browser (Firefox Daylight 36.0 in iOS 12.4) the toggle didn't appear in the menu on the mobile page (en.m.wikipedia.org) where it's shown here, and when I switched to the "desktop site" (for which I use the Vector Legacy skin), there was just a gap of blank space at the top right of the page between "Beta" and "Watchlist" where the toggle link would normally appear. - LaetusStudiis ( talk) 16:07, 15 March 2023 (UTC) reply

@ LaetusStudiis in Special:Preferences#mw-prefsection-gadgets be sure you opt-ed in to "dark mode toggle", not the "core styling" one the bottom. Then try reloading the page, ensure you have javascript enabled as well. — xaosflux ^Talk 18:01, 15 March 2023 (UTC) reply

Oh wait, did you say Firefox 36? From 2015? Try using a current browser as well. — xaosflux ^Talk 18:02, 15 March 2023 (UTC) reply

Unfortunately not an option because Apple forces all other browsers to use their rendering engine on mobile. The only option the user has is to get a new device. Izno ( talk) 19:53, 25 April 2023 (UTC) reply

Hi, I'd like to point out that this annoying problem with the Wikipedia dark mode has been around for a long time. In fact files are not showing correctly, but they are all blurry. For example like these ones:

Perseverance (rover)#/media/File:Perseverance-Selfie-at-Rochette-Horizontal-V2.gif

Perseverance (rover)#/media/File:PIA23499-Mars2020Rover-FirstTestDrive-20191217a.jpg

Curiosity (rover)#/media/File:Drawing-of-the-Mars-Science Laboratory.png

Interstellar probe#/media/File:Near-stars-past-future-en.svg Briskola ( talk) 08:40, 9 April 2023 (UTC) reply

Can't reproduce in Safari on macOS. @ Briskola What version of Safari are you using? – SD0001 ( talk) 13:00, 18 April 2023 (UTC) reply

It was from version 16.2, now on 16.4.1 everything seems to work Briskola ( talk) 07:56, 19 April 2023 (UTC) reply

I enabled the gadget and don't see a "Dark mode" switch at the top of pages. MBH ( talk) 04:29, 7 May 2023 (UTC) reply

Open the user menu. Nardog ( talk) 04:31, 7 May 2023 (UTC) reply

Nardog, what is "user menu"? MBH ( talk) 08:17, 8 May 2023 (UTC) reply

The button with . If you don't see it, which skin are you using? Nardog ( talk) 08:49, 8 May 2023 (UTC) reply

This button is not a menu, it's a link to my userpage. Vector 2010. MBH ( talk) 10:14, 8 May 2023 (UTC) reply

Then you should see it between Beta features and Watchlist. If you don't, make sure JavaScript is enabled and your browser is up-to-date. Nardog ( talk) 11:20, 8 May 2023 (UTC) reply

OK, I see and use it, thanks. MBH ( talk) 18:56, 8 May 2023 (UTC) reply

Seems like table colors are distorted and not showed properly in dark mode on both Chrome and Safari. Visit this page to get a full view of this issue. IPad#Operating system support Briskola ( talk) 22:27, 31 May 2023 (UTC) reply

No, visiting that page didn't give me a full view of what the issue is. Please explain. Nardog ( talk) 02:11, 1 June 2023 (UTC) reply

Hi, when i use visual mode to edit, the thumbnails color looks like this. This only occurs on visual mode editing. আফতাবুজ্জামান ( talk) 23:30, 21 July 2023 (UTC) reply

This edit request to MediaWiki:Gadget-dark-mode.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Please add

html .oo-ui-searchWidget-results .oo-ui-iconElement-icon,

after line 54. This will fix the issue. – SD0001 ( talk) 09:38, 10 August 2023 (UTC) reply

SD0001 -  Done. ~Oshwah~ ^{(talk) (contribs)} 02:13, 30 August 2023 (UTC) reply

CHAM-
PA

500

SASANIAN
EMPIRE

BYZANTINE
EMPIRE

NORTHERN
WEI

HYMYAR

SOUTHERN
QI

Alchon
Huns

Nezaks

TOCHA-
RIANS

ZHANGZHUNG

FUNAN

TUYUHUN

GUPTA
EMPIRE

HEPHTHALITES

ROURAN KHAGANATE

Kyrgyzs

Gaoju
Turks

Yueban

Magyars

Sabirs

Alans

Kutrigurs

Venedae

Finnish

Ugrians

Yakuts

Bashkirs

Antes

GOGU-
RYEO

AKSUM

◁ ▷

class=notpageimage|

Main polities in continental Asia circa 500.

Hi! I created the following template map with hyperlinks, but the text of the hyperlinks nearly disappears in dark mode. Does anyone know what sort of code I should add to the template in order to exempt it from dark mode? पाटलिपुत्र (Pataliputra) (talk) 06:33, 10 August 2023 (UTC) reply

Add mw-no-invert class to the span element containing the text. – SD0001 ( talk) 08:35, 10 August 2023 (UTC) reply

@ SD0001: Thank you very much! It indeed works by adding the class="mw-no-invert" attribute inside the span code, as in <span class="mw-no-invert" style="color:#4F311CFF">500</span> to print 500 without the color being affected by the Dark Mode. Great! Thank you again. पाटलिपुत्र (Pataliputra) (talk) 09:16, 10 August 2023 (UTC) reply

Before I get to this issue, I would like to first express my hearty thanks for this gadget, as it would seem to obviate the need to use the Dark Reader extension for Firefox on Wikipedia. Curiously, though, I do wonder if that might considerably reduce the memory usage from Firefox if using this gadget's dark mode instead of the extension. Would be interesting to test and see if there are any significant difference. Hmm.

Anyway, now as to the issue in question... This gadget appears to not work with the user preference. There seem to be no information about this in the documentation, at least under the "Limitations" heading, nor do I see any mention of this in this talk page. Is this a bug, or simply just an undocumented limitation? Or at least a conscious decision to exclude the user preference pages from the effects of this gadget? Legion ( talk) 14:03, 17 September 2023 (UTC) reply

Gadgets don't load at all on the preferences page. If they did, someone could write a malicious gadget that once enabled hacks the preferences screen and prevents you from disabling it. – SD0001 ( talk) 14:25, 17 September 2023 (UTC) reply

Shouldn't this page describe accessing this mode with a URL hack?

• httpWikipedia/wiki/page?withgadget=dark-mode
• httpWikipedia/?title=page&withgadget=dark-mode

-- 65.92.247.90 ( talk) 03:12, 30 October 2023 (UTC) reply

Having followed the instructions for activating the dark mode toggle in prefs, I still have no toggle. It's not difficult, so I'm not sure why I'm not getting it. Logging out and back in didn't help, but it's still checked off in prefs. Some bug with working with Firefox? — Preceding unsigned comment added by Sendtosynergy ( talk • contribs) 22:02, 30 November 2023 (UTC) reply

Is this gadget can be automated based on user's local time? 98 𝚃𝙸𝙶𝙴𝚁𝙸𝚄𝚂 16:05, 1 January 2024 (UTC) reply

Yes, if your OS supports it. Per the documentation, you can put window.wpDarkModeAutoToggle = true; in your common.js page so that dark mode is activated when the OS switches to dark mode. – SD0001 ( talk) 19:15, 1 January 2024 (UTC) reply

Thanks a lot and happy new year to you @ SD0001. 98 𝚃𝙸𝙶𝙴𝚁𝙸𝚄𝚂 20:40, 1 January 2024 (UTC) reply

As someone who occasionally gets scintillating scotoma thank you very much for dark mode.

I cannot remember what the name of the thing is which turns on the colors in source editor as I have had it switched on for so long as it really helps with source editing.

When I go to dark mode the colors in the source editor go and the text is just white.

Could we possibly have both dark mode and source editor colors (they don’t have to be same colors)?

I am on ipad with Vector 22. Chidgk1 ( talk) 18:00, 28 January 2024 (UTC) reply

Dark mode works well with the official syntax highlighting – see WP:HILITE for how to enable. It sounds like you are instead using the gadget version ( mw:User:Remember the dot/Syntax highlighter) with which most colors are becoming white in dark mode. – SD0001 ( talk) 20:33, 28 January 2024 (UTC) reply

The banner use CSS background image to create images and they are all reversed. So the Dark Mode needs to reverse whole banner added to Wikipedia. I don't see the banner anymore so I'm not able to share the HTML for it. jcubic ( talk) 14:14, 2 February 2024 (UTC) reply

Link to view the banner in dark mode: https://en.wikipedia.org/?title=Main_Page&withgadget=dark-mode&banner=wikilovesfolklore2024c_banner&force=1

One way to fix would probably be to ask at meta:CentralNotice/Request/Wiki Loves Folklore 2024 for the mw-no-invert class to be added to the banner's div element. – SD0001 ( talk) 00:43, 3 February 2024 (UTC) reply

In Safari, setting auto dark mode window.wpDarkModeAutoToggle = true; causes dark mode to be enabled when changing the system theme from light to dark, but does not cause light mode to be enabled when changing the system theme from dark to light. April Arcus ( talk) 21:14, 9 February 2024 (UTC) reply

Which version of Safari and on which OS? I can't reproduce on Safari 16.5 on macOS. – SD0001 ( talk) 03:18, 10 February 2024 (UTC) reply

macOS 14.2.1, Safari 17.2.1 April Arcus ( talk) 18:57, 12 February 2024 (UTC) reply

The module still has two red errors. Perhaps that should be looked at!  Kind regards,    Rodejong    ^💬 Talk  ^✉️ Email   ^📝 Edits   ^👀 Auth →  21:38, 27 February 2024 (UTC) reply

That seems to be a problem with the validator, not the script. Do you have a specific proposed change? — xaosflux ^Talk 23:44, 27 February 2024 (UTC) reply

The CSS linter in CodeEditor is very old, just ignore them. Nardog ( talk) 23:56, 27 February 2024 (UTC) reply

Even though it's old, shouldn't it be rectified? I am no wizzkid where it is coding concerned. But the Error warning isn't there for fun sake? I wanted to import it to my wiki, but saw the errors and got in doubt!  Kind regards,    Rodejong    ^💬 Talk  ^✉️ Email   ^📝 Edits   ^👀 Auth →  00:07, 28 February 2024 (UTC) reply

With the Vector Legacy and Chameleon skin we are still seeing a duplicate main image/logo show up when dark mode is enabled. I thought I read this was fixed and I checked to see we're using the most recent code, not sure what I am missing and hopefully somebody has some insight?

Additional question - how would I change the text that appears in the preferences for the user to enable this feature? Right now it says ⧼gadget-section-dark-mode⧽ in a bold header and then below has a checkbox next to ⧼gadget-dark-mode⧽. It may present better with a header of "Dark Mode" and next to the checkbox it says "Dark Mode Enabled." Thank you. Kimmywingz ( talk) 19:51, 4 March 2024 (UTC) reply

We don't do technical support for non-Wikimedia wikis here. And if you have your own MW installation, installing a skin that supports dark mode would make much more sense than installing this gadget, which is/was a kludge to what Wikimedia users are stuck with and uses inversion filter instead of being an actual dark mode. Nardog ( talk) 00:27, 5 March 2024 (UTC) reply

Thank you for this information. Kimmywingz ( talk) 14:29, 5 March 2024 (UTC) reply

As you may have read the WMF (I am in this team) is working on a dark mode feature. While one response to this could be to disable the gadget for skins which have their own dark mode (or remove it altogether), I imagine there will be some users who will prefer the existing gadget, just as there were some users who preferred the NavigationPopups to the page previews feature.

With the assumption we will keep both, I was wondering what we need to do to get them working side by side. If I enable night mode with the gadget on https://en.m.wikipedia.org/wiki/%C5%9Eilan_Ayy%C4%B1ld%C4%B1z?minervanightmode=1 we get an interesting theme as a result 🙃.

There are a few things we could do if a user has set the default night mode scheme and also enabled the gadget:

• The gadget could detect and turn the skin dark mode off:

  document.documentElement.classList.remove('skin-theme-clientpref-night'  )

• The gadget could detect dark mode and refuse to run e.g. use mw.notify to say that the gadget is not running
• The gadget CSS could be modified to only apply when the skin night mode has been disabled e.g. html:not(.skin-night-mode-clientpref-1):not(.skin-night-mode-clientpref-2) { filter: invert(1) hue-rotate(180deg); }

Thoughts @ MusikAnimal @ Nardog @ TheDj Jdlrobson ( talk) 22:15, 9 March 2024 (UTC) reply

My initial thought was option 2, but the mw.notify etc could become unwieldy. Also considering that skin night mode is so easy to switch off, I think it's worth allowing users to switch directly from that to the gadget dark mode, so my vote is for option 1. Option 3 is not really practical as there's no on-wiki Less, so you would have to modify almost every single line in MediaWiki:Gadget-dark-mode.css – SD0001 ( talk) 11:30, 10 March 2024 (UTC) reply

How is the skin dark mode toggled? Does it just follow the media query or can it be opted in/out? Nardog ( talk) 11:35, 10 March 2024 (UTC) reply

> How is the skin dark mode toggled?

For users, it will be possible to opt in and out of the theme. In the mobile settings for Minerva this will appear on Special:MobileOptions and in the side bar for Vector 2022 (check out the existing "Accessibility for Reading (Vector 2022)" feature on Special:Preferences#mw-prefsection-betafeatures to see what it looks like). There will be an automatic, dark and light mode. The automatic mode tells it to follow the browser settings.

Technically, all these modes will be associated with a class on the HTML tag (skin-night-mode-clientpref-0, skin-night-mode-clientpref-1, skin-night-mode-clientpref-2). The latter will be associated with a prefers color-scheme media query. Removing the classes should be enough to disable the associated styles. Jdlrobson ( talk) 20:22, 10 March 2024 (UTC) reply

Good ping for @ TheDJ. Izno ( talk) 03:36, 11 March 2024 (UTC) reply

dark mode in wikidata main page removing a box (Welcome to Wikidata). it only appears in the light mode. KuldeepBurjBhalaike ^{( Talk)} 08:47, 11 March 2024 (UTC) reply

It’s still in light theme — Preceding unsigned comment added by Weegie69 ( talk • contribs) 02:42, 25 March 2024 (UTC) reply

The iphone 6 is 10 years old, so it's likely that the gadget depends on some features not yet available to that phone. — TheDJ ( talk • contribs) 13:53, 1 April 2024 (UTC) reply