Wikipedia talk:Dark mode (gadget)

Wiktionary

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

Meta global

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

Infobox please

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)

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

Please do not use (almost) black as background with white foreground

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)

+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)

+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)

+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)

+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)

css only or both?

@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)

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)

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)

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

Kind of broken still

@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)

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)

@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)

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 img[src*='svg'],
 html img[src*='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)

Minor bug report: @ character displaying black in Template:No spam

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)

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)

Noticed a bug

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)

What is this supposed to look like?

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)

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

Map legends

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)

Exclude element from dark theme

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)

@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)

@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)

@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)

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)

@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)

Toggle functionality as a gadget

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)

Interface-protected edit request 28 November 2021

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)

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

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

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

@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)

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

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

@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)

Interface-protected edit request on 17 December 2021

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)

@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)

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 resolution ppi monitor. P.T.Đ (talk) 12:37, 18 December 2021 (UTC)

 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)

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)

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)

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)

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)

@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)

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)

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)

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)

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)

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)

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)

@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)

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)

Interface-protected edit request 24 December 2021

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)

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

Template:Legend

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)

Exact colors

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)

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)

ogv.js fix

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)

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

iOS minerva address-bar color

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)

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

Fixed elements are movable, Text on SVGs, and Black color

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! ⇒ AramTalk 21:59, 19 January 2022 (UTC)

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)

hue-rotate messes up colours on image

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)

some markup is not visible in edit mode

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)

table with locked-in-place header has images dragging across it

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)