+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. 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? — xaosfluxTalk18: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]
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. — MusikAnimaltalk20: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! — xaosfluxTalk21: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. — MusikAnimaltalk22: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?
@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? — xaosfluxTalk15: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. — MusikAnimaltalk01:40, 26 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 • c16: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 • c06: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):
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]
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]
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.
Above: Now Below: Use text-shadow 0 0 0@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 resolutionppi 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. — xaosfluxTalk16: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. — xaosfluxTalk17: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. — MusikAnimaltalk18: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. — xaosfluxTalk19: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.)
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]
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]
@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]
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}}
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]
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.
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! ⇒ AramTalk21: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 | Talk09:30, 8 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.
Screenshot for further details. (Skin is Vector2022)
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]
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. Blofeld16:36, 4 May 2022 (UTC)[reply]
Filter causes position:fixed elements to behave like position:absolute in Firefox
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]
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.
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? — xaosfluxTalk00: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]
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;
}
}
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]
@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:
/**:: * 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-documenturl-prefix(){::@supportsnot(overflow-clip-margin:1px){::body{::background:#000;::}::}::}
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 may not have waited long enough, but it doesn't seem that the last snippet above alone fixes the current firefox issue. — xaosfluxTalk20: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]
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.
@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]
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]
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]
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.
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
Dull colors in images and svgs in macOS + iOS Safari and Chrome
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]
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]
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]
Issues with dark mode with images, svg and gif on Safari browser
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:
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]
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]
@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]
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]
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]
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)?
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]
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]
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]
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.
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); }
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]
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]
The background should be shifted to a slightly bluer hue, similar to the beta feature of Vector 2022. While previously black text turns white, the colors of links have not been adjusted to match the darker background. The links should have a slightly brighter shade of blue. Additionally, any halo effects around, for example, article previews when hovering over a link, should be completely removed, as they make reading uncomfortable. –Tobias (talk) 15:59, 5 July 2024 (UTC)[reply]
Done (it still complains about invalid rule 
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)
Not done for now: Emiliocobosalvarez / Volker E. (WMF) Please see TheDJ's comment. Izno (talk) 19:41, 3 June 2022 (UTC)
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)
. HLHJ (talk) 01:07, 1 August 2022 (UTC)
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)
, as you can see, appears inverted in Dark Mode. Is this deliberate? סשס Grimmchild. He/him, probably 08:43, 6 December 2022 (UTC)
. If you don't see it, which skin are you using? Nardog (talk) 08:49, 8 May 2023 (UTC)
#/media/File:Perseverance-Selfie-at-Rochette-Horizontal-V2.gif){kind=link}
#/media/File:PIA23499-Mars2020Rover-FirstTestDrive-20191217a.jpg){kind=link}
#/media/File:Drawing-of-the-Mars-Science_Laboratory.png){kind=link}
.png)