Wikipedia:Interface administrators' noticeboard

Dark mode toggle gadget

Wikipedia:Village pump (technical)#Make dark mode toggle script a gadget? appears to have consensus.

Implementation would essentially involve:

•  Done Moving User:SD0001/dark-mode-toggle.js to MediaWiki:Gadget-dark-mode-toggle.js.
•  Done Adding to MediaWiki:Gadgets-definition under Appearance section, perhaps just below "Use a black background with green text" as the two are similar: dark-mode-toggle [ResourceLoader | targets = desktop, mobile | dependencies = mediawiki.util, mediawiki.api, mediawiki.Uri, mediawiki.storage, es6-polyfills | skins = vector, monobook, modern, minerva, timeless] | dark-mode-toggle.js
•  Done Creating MediaWiki:Gadget-dark-mode-toggle with [[User:Volker E. (WMF)/dark-mode|Dark mode]]: Use a light text on dark background color scheme (can be toggled on/off)
•  Done Changing MediaWiki:Gadget-dark-mode to [[User:Volker E. (WMF)/dark-mode|Dark mode]]: Use a light text on dark background color scheme (Internal – use the [[#mw-input-wpgadget-dark-mode-toggle|toggle gadget above]] instead)

Per @MusikAnimal's comment, this marks the existing styles gadget as "internal". – SD0001 (talk) 10:09, 14 December 2021 (UTC)

@SD0001 and Volker E. (WMF): we already have dark-mode[ResourceLoader|targets=desktop,mobile|skins=vector,monobook,modern,minerva,timeless]|dark-mode.css (Use a light text on dark background color scheme) in gadgets - are both of these being kept? Is there a problem if a user enables both at the same time? — xaosflux ^Talk 11:45, 14 December 2021 (UTC)

The relationship between the two has been discussed in the two VPT threads. To recapitulate:

• the existing dark-mode gadget loads just the CSS
• toggle functionality relies on programmatically flipping on/off the CSS gadget in user preferences (so obviously the toggle can't be made part of the CSS gadget)
• so we call the toggle gadget as the "dark mode" gadget. The CSS gadget is necessary for internal use, but can't be hidden from preferences, so we modify its description to note that it's internal (bullet 4 above).

– SD0001 (talk) 12:35, 14 December 2021 (UTC)

@SD0001: why can't we mark it "hidden" like we do with other helper gadgets like Twinkle-pagestyles[hidden|skins=vector]|Twinkle-pagestyles.css? — xaosflux ^Talk 14:25, 14 December 2021 (UTC)

Is it so users don't get "stuck" on or off or something? @MusikAnimal: ? — xaosflux ^Talk 14:26, 14 December 2021 (UTC)

It's because hidden gadgets can't be enabled/disabled in user preferences, even by the API – which is how the toggle is supposed to enable or disable dark mode. – SD0001 (talk) 14:37, 14 December 2021 (UTC)

OK thanks, so users could still just use it manually if they wanted to I suppose. — xaosflux ^Talk 15:32, 14 December 2021 (UTC)

•  Done — xaosflux ^Talk 11:59, 15 December 2021 (UTC)

Great work, all! But I think there's more to be done. We talked about moving the links to #p-personal, but that can wait. More important is not having the two gadgets side by side in the list, which is rather confusing from a usability standpoint. Right now things are designed with a CSS-only gadget and then a toggle gadget, but that's purely out of technical necessity. I suspect most will want the luxury of easily toggling it on/off (especially for a dark mode that uses the invert() CSS filter which inevitably will produce some sort of visual bug). The problem is how to accommodate those who have the CSS gadget on but not the toggle.

What if we add a MediaWiki:Gadget-dark-mode.js that checks if dark-mode-toggle is enabled, and if not, enables it and loads the JS? Is that too hacky and/or weird?

Also I think we should link to Wikipedia:Dark mode from the gadget descriptions, and amend the page to document the gadget first and foremost, with the other content below it.

Then finally moving the toggle to p-personal as discussed at WP:VPT. That will require a little more care, since we need to use peer gadgets to ensure the links don't "jump" in p-personal, and that it looks good in mobile view. It can be done though, and I'll gladly take a stab when the time comes.

Once all of that is done, I feel like we'll be in a good place to start talking about enabling the gadget for all users. And that, in turn, may argue that mw:Extension:DarkMode could possibly have a second chance at deployment (since we're basically reproducing it locally in a rather hacky way)… but one step at a time :) — MusikAnimal ^talk 06:03, 16 December 2021 (UTC)

Moving links to #p-personal - @Nardog already set that in motion, but there's still no css to avoid the "jump". Should we add the CSS as a new peer gadget, or just add it along with dark-mode CSS?
I think the confusion from having two gadgets could be solved by more tactful gadget descriptions – maybe create an "Internal" section at the bottom and move the styles gadget there?
What if we add a MediaWiki:Gadget-dark-mode.js that checks ... As Izno mentioned on VPT, the base dark-mode gadget can't contain anything other than CSS – it ceases to be render-blocking if any JS is added into it, leading to FOUCs. If you are suggesting this as a way of enabling the toggle for existing dark-mode users, how about putting some temporary code in mediawiki:group-user.js to that effect (if kept for 30 days, anyone who logs in within that time is sorted)? – SD0001 (talk) 17:42, 16 December 2021 (UTC)

Yeah I saw it was moved to p-personal. I'll try to work on the peer CSS soon. I believe dark-mode-toggle needs a peer gadget to reserve the space for the "Dark mode" text and dark-mode.css would reserve the space for "Light mode". That should work I think. I'll test it out on Test Wikipedia first.

I have moved dark-mode back to the bottom of "Testing and development" and change the description to be as you suggested, encouraging use of the toggle. I now understand why we can't have a dark-mode.js, thanks for explaining. I don't think we need to bother with adding special temporary code to Group-user.js or what have you. Those who have only the CSS gadget enabled will eventually discover the toggle gadget. — MusikAnimal ^talk 18:21, 16 December 2021 (UTC)

This pretty much solves the jumping effect:

.skin-vector-legacy :not(#pt-darkmode) + #pt-watchlist::before,

.skin-monobook :not(#pt-darkmode) + #pt-watchlist::before { content: "Dark mode"; visibility: hidden; margin-left: inherit; } The content of the pseudo-element must be hard-coded, so it won't reflect the label in mw.messages—probably a non-issue as long as the JS and CSS cross-reference each other in comments. A bigger problem is that if the dark mode is on, there will still be a slight jump because the toggle will show up as "Light mode". Come to think of it, I don't even know if the toggle should show different labels at all—it's pretty clear what a button called "Dark mode" does when you're already in the dark mode. I've found "Light mode" a bit clumsy anyway. Nardog (talk) 13:33, 17 December 2021 (UTC)

The jump while in dark mode can be removed by adding the same style with higher specificity (but with content: "Light mode") in dark-mode.css. – SD0001 (talk) 15:18, 19 December 2021 (UTC)

@Nardog @SD0001 I've got this working over at Test Wikipedia, if you want to try it out (look for "dark-mode-toggle" at testwiki:Special:Preferences#mw-prefsection-gadgets). Used both of your suggestions (thank you!). If it all looks good to you I'll get this implemented here on enwiki.

This does mean folks with only the CSS gadget will have a mysterious blank space in their p-personal; but when inquiries come in at VPT or elsewhere, we simply instruct them to enable the toggle gadget, hopefully without any complaints. — MusikAnimal ^talk 22:54, 20 December 2021 (UTC)

It works! I don't think visibility: hidden; margin-left: inherit; is necessary in dark-mode.css though, and I would use something like body.skin-vector-legacy :not(#pt-darkmode) + #pt-watchlist::before to avoid the need for !important. Nardog (talk) 05:06, 21 December 2021 (UTC)

I had added a #p-personal to get around having to use !important, but then forgot to remove the !important, heh. Using body.skin-vector-legacy seems more greceful, anyway, so done, and same with removing the redundant properties that come with dark-mode-pagestyles.css. I'll implement this on enwiki shortly. — MusikAnimal ^talk 05:53, 21 December 2021 (UTC)

Okay, deployed :) I'm only noticing now that there are some issues with the correct dark/light mode text being the opposite of what it should be, or the stylesheet didn't load. It doesn't always remember your preference browsing page to page, either. Or some combination of before mentioned issues. It's a JS issue unrelated to these changes. I can try to take a look but please feel free to do the same. — MusikAnimal ^talk 06:12, 21 December 2021 (UTC)

I don't see any issue. Toggling and rapidly navigating to another page may load the old mode – which is an expected race condition as the server is sending the new page just as the user preference is changing, but not exactly a bug as the mode change is still registered and reflected on subsequent navigation. Not sure if it's worth adding a beforeunload handler to stop navigation till the API response is received ... – SD0001 (talk) 13:57, 21 December 2021 (UTC)

Yes doing more testing today, I believe it's just the race condition when toggling and changing pages, which may be more noticeable on testwiki. This probably isn't something people will experience during normal day-to-day usage, rather I found it only because I was doing rigorous testing. If we hear more complaints we can look into adding the beforeunload handler. — MusikAnimal ^talk 17:05, 21 December 2021 (UTC)

A less intrusive way than beforeunload is to keep the preference in localStorage (or perhaps sessionStorage) on toggling, and if it doesn't match the value in mw.user.options when the script is loaded, turn it on/off according to the storage value (or double-check with the server and then turn it on/off). Nardog (talk) 03:04, 22 December 2021 (UTC)

Clever! sessionStorage would maybe make more sense here because it's only meant to carry over multiple requests in quick succession, and it'll expire on its own. If you are willing to code this up I'd be happy to help test and sync here. Which gets me thinking, is it worth giving this pair of gadgets a repository over at https://github.com/wikimedia-gadgets/ ? — MusikAnimal ^talk 03:57, 22 December 2021 (UTC)

Thanks. I think a comment at the beginning of dark-mode-toggle.js saying the labels in the script and in the two CSSes should match would be nice. Nardog (talk) 06:17, 21 December 2021 (UTC)

Good idea.  Done — MusikAnimal ^talk 16:52, 21 December 2021 (UTC)

@MusikAnimal and @Nardog: I've created Wikipedia:Dark mode (gadget) with instructions on setting up the gadget, for the benefit of other wikis. User:Volker E. (WMF)/dark-mode doc page was rather messy, and WP:Dark mode title was already taken for an overview. Let me know if all looks good. Then, we can put out a note in Tech News. – SD0001 (talk) 18:29, 2 January 2022 (UTC)

If this is the new documentation, it should get linked here: MediaWiki:Gadget-dark-mode-toggle. — xaosflux ^Talk 22:48, 2 January 2022 (UTC)

@SD0001 Thanks for creating centralized documentation! I am very fond of spreading this idea to more wikis such as through Tech News. If it catches on, perhaps that would be enough to convince whomever that the community is content with a CSS filter-based solution, and mw:Extension:DarkMode will have a chance. Assuming that won't happen, I think we should go the meta:MoreMenu route and instruct other wikis to import the gadget from here, offering a means to localize messages -- either through edit request here or perhaps sourcing a local file (JSON behind ResourceLoader is coming very soon, by the way!). Aside from the messages and the CSS tweaks which each wiki could also independently make, is there any reason for them to "copy" our gadget? I was even thinking we should move the docs and source files to Metawiki, but I don't see that as a necessity. — MusikAnimal ^talk 06:20, 3 January 2022 (UTC)

Lol, JSON behind ResourceLoader is coming very soon, by the way! – I said that as if you didn't already know ṫhat… silly me, sorry I neglected to realize you were the author (and sorry I wasn't much help with reviewing, by the way)! This is an exciting feature I'm very much looking forward to, and I think i18n messaging would be a good use for it. — MusikAnimal ^talk 06:26, 3 January 2022 (UTC)

@MusikAnimal For the JS toggle, you're right - it can also be dynamically loaded, especially since the i18n messages could soon be moved to a json file. But the CSS gadgets would have to be copied to avoid FOUCs. Overall, the Gadgets extension still leaves a lot to be desired. I just filed phab:T298561 for better ways to handle cross-wiki gadgets, which would remove the need to copy the CSS files – and even avoid having to do an mw.loader call for loading the JS (it could be loaded through gadget definition itself). – SD0001 (talk) 21:06, 4 January 2022 (UTC)

Now added to m:Tech/News/2022/06. – SD0001 (talk) 11:32, 30 January 2022 (UTC)

@SD0001 Sorry I've been so busy I haven't had time to come back to this; are we sure we want to encourage copy/pasting our gadget? I would strongly advise against it. If they have to copy/paste the CSS, so be it, but I imagine over time we'll want to make updates to the JS and we surely don't want to go through what I did with the multi-month (and still incomplete) effort at meta:MoreMenu/Migration.

Starting this week I'll have a little more time on my hands and am happy to help with this, including moving the localization strings to JSON if we feel that is worthwhile? — MusikAnimal ^talk 22:16, 30 January 2022 (UTC)

Also, is it just me or does the demo link not work anymore? — MusikAnimal ^talk 22:21, 30 January 2022 (UTC)

@MusikAnimal: looks like mw:Extension:Gadgets#supportsUrlLoad may be enforced now; so MediaWiki:Gadgets-definition would need a definition update to support it. — xaosflux ^Talk 11:08, 31 January 2022 (UTC)

SD0001 isn't "encourag[ing] copy/pasting our gadget", at least at Wikipedia:Dark mode (gadget)#Setting up the gadget on your wiki. Nardog (talk) 16:09, 31 January 2022 (UTC)

You're right, sorry, I see we are now suggesting loading the enwiki gadget. It was the … MediaWiki:Gadget-dark-mode-toggle.js by copying the English Wikipedia versions bit that confused me. So we're not asking they load our gadget, just suggesting it, but that's still better than nothing. I withdraw my concern. If this gadget takes off and gets enabled on a lot of wikis, that may be enough to influence WMF to give mw:Extension:DarkMode another chance, in which case we'll nuke all the gadgets anyway (nullifying the need for them to source our gadget for long-term maintenance purposes). — MusikAnimal ^talk 17:11, 31 January 2022 (UTC)

Yeah the wording had been adjusted (this edit). Feel free to adjust it further to more strongly encourage the dynamic load option – I just couldn't come up with better phrasing. Still a week for the Tech News issue to go out, so no rush! – SD0001 (talk) 18:01, 31 January 2022 (UTC)

Regarding using JSON for localisation strings – the trouble is that I don't think that approach is compatible with the idea of other wikis dynamically loading the JS file. require is undefined when loading from ?index.php&action=raw. On the other hand, if ?load.php&only=scripts URL is used, require will work but it will load in the enwiki JSON file. – SD0001 (talk) 18:05, 31 January 2022 (UTC)

BOTN request regarding 2x redirects

Just wanted to draw attention to WP:BOTN#Double redirects for user's scripts for your review. I think I took care of everything sensibly, but take a look at the relevant links there if you haven't yet. Izno (talk) 08:40, 3 January 2022 (UTC)

Izno - I went through the list at Special:DoubleRedirects, found a couple of .js and .css pages in the user space of accounts that have since been renamed twice, and fixed those double-redirects. Other than that, all looks good to me. Everything else on that list can be fixed by non-interface admins. :-) ~Oshwah~^{(talk) (contribs)} 08:00, 9 January 2022 (UTC)

Izno - Nevermind. I just realized that you left those double-redirects on purpose due to a rename-process that was performed out of order. I've undone those changes. Sorry about that! ~Oshwah~^{(talk) (contribs)} 08:05, 9 January 2022 (UTC)

Tech news 2022-02

Lots of juicy stuff for gadget writers and interface admins with the recent deployment courtesy SD0001. See WP:VPT#Tech News: 2022-02. Izno (talk) 03:57, 11 January 2022 (UTC)

Some good stuff in there! Enterprisey (talk!) 23:10, 11 January 2022 (UTC)

One of the changes in there has been dismissed as insecure, phab:T29766#7611796. It seems even interface-admins can't be trusted anymore. – SD0001 (talk) 05:08, 12 January 2022 (UTC)

Request for content model change for user CSS page

Hi - I'm trying to implement a template in my userspace which will allow the use of a particular font custom for use in my signature. Unfortunately it seems that TemplateStyles requires "Sanitized CSS" content model, but CSS pages created in userspace are just the "CSS" model by default. As such, TemplateStyles throws up an error message about the content model. Would it please be possible for someone to manually convert the CSS page in my user space to Sanitized CSS? It's User:Theknightwho/Doves Type/fonts.css. Theknightwho (talk) 23:28, 12 January 2022 (UTC)

Not done @Theknightwho: your current code contains at least one error incompatible with SCSS (Invalid or unsupported value for property src at line 3 character 8.). I created a new SCSS page for you at User:Theknightwho/Doves Type/fonts2.css which you can either build instead, or use to sandbox your changes. — xaosflux ^Talk 23:34, 12 January 2022 (UTC)

a particular font custom for use in my signature Please don't. Wikipedia:Signatures#NoTemplates. Nardog (talk) 23:35, 12 January 2022 (UTC)

Understood. Thanks. Theknightwho (talk) 23:38, 12 January 2022 (UTC)

Beyond not using templates, please don't make others download a font to see your signature. isaacl (talk) 23:47, 12 January 2022 (UTC)

100%; but if they want this to just use with a js to restyle their sig for only themselves, that's not so much a problem. — xaosflux ^Talk 23:50, 12 January 2022 (UTC)

For which it should be in their common.css or skin.css, not in a TemplateStyles page. Izno (talk) 00:53, 13 January 2022 (UTC)

Proposal to block reFill edits

Page watchers may be interested in WP:VPPRO#RfC: Block reFill tool until fixed. Izno (talk) 22:31, 21 January 2022 (UTC)

• Thanks for the note, though I don't think there is going to be pretty much anything for intadmins to do here? — xaosflux ^Talk 22:57, 21 January 2022 (UTC)

  I hadn't remembered it was not local (sourced either directly to Toolforge or to the meta version), but regardless, I like to think it makes sense to attempt to reach gadget-savvy (JavaScript/CSS) editors here generally, and specifically in this case one might be able to correct the issue by fixing the script. Izno (talk) 23:02, 21 January 2022 (UTC)

  Oh for sure, and if there is a good fix that can be made on the meta script, I can make it over there, but for the most part major work is happening on toolforge, even on the meta script. — xaosflux ^Talk 23:05, 21 January 2022 (UTC)

Unlocking

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Can someone remove the script from User:AssumeGoodTest/common.js? I may use the account for future tests. – AssumeGoodWraith (talk | contribs) 13:09, 27 January 2022 (UTC)

Ownership link: Special:Redirect/logid/126865922. — xaosflux ^Talk 13:24, 27 January 2022 (UTC)

@AssumeGoodTest and AssumeGoodWraith:  Done — xaosflux ^Talk 13:26, 27 January 2022 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Request

There is a request at MediaWiki talk:Gadgets-definition which is categorised as a full protection request, but is actually an interface protection request, if someone would like to look at it? Cheers — Martin (MSGJ · talk) 13:15, 31 January 2022 (UTC)

Fixed the queue, someone should get to it soon. — xaosflux ^Talk 15:10, 31 January 2022 (UTC)

supportsUrlLoad

Page watchers may be interested in MediaWiki talk:Common.js#supportsUrlLoad. Izno (talk) 20:00, 1 February 2022 (UTC)