Wikipedia:Interface administrators' noticeboard

Welcome to the interface administrators' noticeboard
This is the interface administrator noticeboard, for discussion of interface administrators and coordination of edits to the interface. Currently only interface administrators can undelete JS/CSS pages, if you have an uncontroversial undelete or deleted version retrieval request, please list it below. Any administrator can delete JS/CSS/JSON pages, for speedy deletions just use a CSD template on the page or its talk page. Individual requests for edits to interface or user JavaScript/CSS pages should continue to be made on their respective talk pages.
Click here to start a new discussion

4 interface-protected edit requests v·h
Page Tagged since Protection level Last protection log entry MediaWiki:Gadget-WatchlistBase.css (request) 2024-03-02 23:26 Site CSS page (log) MediaWiki:Gadget-watchlist-notice-core.js (request) 2024-03-02 23:26 Site JS page (log) MediaWiki:Vector-2022.css (request) 2024-05-29 01:47 Site CSS page (log) MediaWiki:Common.css (request) 2024-05-31 10:27 Site CSS page (log) Protected by Sam Korn on 2005-07-21: "As with all MW: pages, can't have vandals getting to the styles!"
Updated as needed. Last updated: 19:36, 1 June 2024 (UTC)

Delete broken redirects

User:Nigos/glintwarn.js is a broken redirect and should be deleted by an intadmin. Once that is deleted, User:Anchorvale/glintwarn.js would then also become broken and should be deleted too. GeoffreyT2000 (talk) 18:48, 13 December 2021 (UTC)

 Done — xaosflux ^Talk 19:04, 13 December 2021 (UTC)

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)

Interface administrator assistance needed

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.

---

Hi, can an interface administrator please move Template:Clade gallery/styles-div.css to User:Jts1882/Clade gallery/styles-div.css? This is as a result of Wikipedia:Templates for discussion/Log/2021 December 15#Template:Clade gallery/styles-div.css. ✗plicit 03:24, 22 December 2021 (UTC)

Was this not possible for you? I am surprised, since I'm pretty sure MediaWiki should only have a conniption if you're trying to move unsanitized css content model rather than sanitized-css content model to the user space. Izno (talk) 05:36, 22 December 2021 (UTC)

It’s intentional in MediaWiki namespace, and I suppose it’s intentional in user namespace as well—things like the withCSS URL parameter handler in MediaWiki:Common.js consider page titles ending with .css in the MediaWiki namespace safe, no matter what content model they have. Since this protection also means that only the user themselves and interface admins can edit the TemplateStyles page from now on, maybe it would have been (or would be) better to use a page title not ending in .css, since AFAIK TemplateStyles itself doesn’t consider the page title suffix (except when determining the default content model), it could load the content from, say, User:Jts1882/Clade gallery/styles-div, as long as it has sanitized-css content model. —Tacsipacsi (talk) 14:36, 22 December 2021 (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.

Inactive interface administrators 2021-12-28

The following interface administrator(s) are inactive:

• Ragesoss (talk · contribs · blocks · protections · deletions · page moves · rights · RfA)

— JJMC89 bot 23:18, 28 December 2021 (UTC)

 Done removed. — xaosflux ^Talk 22:48, 2 January 2022 (UTC)