MediaWiki talk:Gadget-site.css/Archive 1

=2006=

New yellow
I'm not sure I like the new yellow - it's a bit garish! --HappyDog 01:06, 18 April 2006 (UTC)


 * I'm not too fond of it either; also, at least one of the developers has referred to it as "urine coloured" and at least one more person has agreed with this view. Rob Church (talk) 18:06, 22 April 2006 (UTC)


 * I know, nobody likes it, me too ;-/ Better suggestions are very welcome, of course. But please keep in mind: We already have enough problems with users who don't understand the different licenses for the namespaces (a lot more hints on this issue have to be written, of course). So this namespace should be "remarkable/striking/whatever" at first glance (NS:Help is in the public domain)), especially for the time being, in which we don't have a namespace-specific sidenotice that is saved with the source if a user saves an article (see bug 4469). We really do need this, and I'm not familiar enough with .js to work out something close within a few days. So an ugly colour seemed to be the best way to get a little more attention for the different namespaces … -- :Bdk: 22:33, 22 April 2006 (UTC)

I've tried something new - a strong blue border around the PD pages. Note that I applied it to Help: only, not to Help_talk:, as I think that PD should not apply to the discussion pages. I have also updated MediaWiki:Copyrightwarning to be clearer, and to stick out more, and have rewritten Project:Copyrights to be clearer and more detailed. I would appreciate it if someone could check that over, as I'm not 100% sure about everything I've written. Hope that makes things a bit better... --HappyDog 12:58, 24 April 2006 (UTC)


 * Hm, looks nicer, definitely, but also less striking (what is not as good IMO). And why do you use border-right: none;, so that it's only a 3/4 border? ;-)
 * But whatever we'll change in the optical way, it is a temporary crook. So I see no other way than creating a proper specific sitenotice for this case (having two licenses in one project) … have to poke someone more *g* -- :Bdk:  14:10, 24 April 2006 (UTC)
 * It's 3/4 border, because that is how it is on all pages. :) What do you reckon to the new copyright notice?  I think it helps a lot. --HappyDog 14:13, 24 April 2006 (UTC)
 * /me hides because of the border ;-) -- :Bdk: 16:58, 25 April 2006 (UTC)

Watermark
I've tried adding a watermark to the PD pages, so there is automatically a mark, even if the PD tag has not been added. To be honest, it looks really bad at the moment, but I'll leave it there for a bit of feedback before deleting. Maybe smaller? Maybe a different location? Different image? We could easily add a small banner that fits into the header section. If we can't get something that both looks good and is clear without being too intrusive then I would suggest scrapping the idea altogether. --HappyDog 15:18, 24 April 2006 (UTC)
 * Well done, much better than the u**** colour, of course. -- :Bdk: 16:58, 25 April 2006 (UTC)

IE 5.5 bug
I've just tested the help namespace in IE5.5, and it looks so very bad - the transparent .png file is not working as it should. I don't know what to suggest, except to fix the background of the image to the background of the namespace. That would fix it but not give us any flexibility in tweaking the ns background. Maybe not a big deal though - once this is sorted I doubt we'll be changing it again. I haven't (can't) test other versions of IE (using FF by the way). --HappyDog 00:18, 26 April 2006 (UTC)

=2007=

Little Bug
When I run the javascript console of firefox 2.0 then I always get a failure message caused by this config.

Please change <pre&gt;<nowiki&gt; to /** <pre&gt;<nowiki&gt; */

and </nowiki&gt;</pre&gt; to /** </nowiki&gt;</pre&gt; */

or something like that.

-- MichaelFrey 05:54, 6 May 2007 (UTC)


 * Thanks, thats good :-) -- MichaelFrey 11:05, 6 May 2007 (UTC)

=2008=

Common.css does not seem to have any impact
Hello, does anybody know why my MediaWiki:Common.css does not make any impact on pages of my wiki? for testing purposes i added the same styles than MediaWiki:Common.css but the pages does not change. can anyone please help me?

this also occurs when i try to edit MediaWiki:Common.js (for adding additional edit buttons). Nothing happens. Will i have to enable this function? Thanks in advance --TurboKanne 13:59, 19 February 2008 (UTC)


 * Older versions of MediaWiki had only skin-specific js/css pages, like MediaWiki:Monobook.js or MediaWiki:Simple.css. System messages Common.css and Commmon.js were added around December 2006. Look at the HTML source of your wiki pages to see if these pages are loaded at all (note that Common.js is called from  "site js" URL. If they are called, check the content inside. If the content is present, get Opera or Firefox, open Error Console and check for js/css errors. —AlexSm 14:45, 19 February 2008 (UTC)


 * Excuse me, I'm interresting by your message. I would like to use the Mediawiki:Monobook.css that we can find here : w:fr:MediaWiki:Monobook.css because I like the ident of the text

/* PAGES DE DISCUSSION : COLORATION INDENTÉE */ .ns-talk dd { margin:0; padding:0; } .ns-talk dl { border-top:solid 1px #F0F080; border-left:solid 1px #F0F080; padding-top:.5em; padding-left:.5em; margin-left:1em; } .ns-talk dl, .ns-talk dl dl dl, .ns-talk dl dl dl dl dl, .ns-talk dl dl dl dl dl dl dl, .ns-talk dl dl dl dl dl dl dl dl dl { background:#FFFFE0 } .ns-talk dl dl, .ns-talk dl dl dl dl, .ns-talk dl dl dl dl dl dl, .ns-talk dl dl dl dl dl dl dl dl, .ns-talk dl dl dl dl dl dl dl dl dl dl { background:#FFE }


 * So I copied the .css on my wiki but the monobook is not used, so ns-talk is not used too.


 * On my page I can read

/*<![CDATA[*/ @import "/index.php?title=MediaWiki:Common.css&usemsgcache=yes&action=raw&ctype=text/css&smaxage=18000"; @import "/index.php?title=MediaWiki:Monobook.css&usemsgcache=yes&action=raw&ctype=text/css&smaxage=18000"; @import "/index.php?title=-&action=raw&gen=css&maxage=18000&useskin=monobook"; /*]]>*/


 * Is it tell me that I can't use Monobook.css ?


 * Can you help me, please ?


 * Thanks !


 * Emmanuel (with Mediawiki 1.13.2)

---


 * It's been a decades since these posts, but I, too, am unable to see desired effect from Common.css. It's 2018, and I'm using the Vector skin in a BlueSpice setup.  The problem is that top bar (header) links are light gray, barely noticeable against a while (or for that matter, dark) background.  In particular, I want to darken the word "EDIT".  So far, I've found no definition that applies to this. I have, however discovered that I can change the Edit window text by modifying Body.  Why it doesn't modify the entire page is a mystery.
 * 69.203.102.97 00:28, 12 February 2018 (UTC)
 * 69.203.102.97 00:28, 12 February 2018 (UTC)

MediaWiki:Monobook.css help page
Is there currently a MediaWiki:Monobook.css help page anywhere? If there is can that be mentioned on MediaWiki:Monobook.css? I can create one at Help:MediaWiki:Monobook.css. Odessaukrain 18:54, 7 April 2008 (UTC)
 * It's CSS specific to the MonoBook skin, as is explained on the default message for that page. I really don't think it needs a PD help page... but if you want to make one feel free. --Skizzerz talk - contribs 00:03, 8 April 2008 (UTC)

Where is common.css??
I am completely new and I cannot find...can someone add the location to the article...Thanks! Do you have to create it in 1.12?? --Jorgusch 14:08, 8 June 2008 (UTC)
 * Since no one else has answered, methinks the following (but haven't proved it works yet, possibly due to caching that's not cleared by CTRL-F5 in IE, seems to happen a bit...)


 * The install of mediawiki puts a bunch of .css files in /skins/common. One of them is not common.css. So I assume you copy the text on the message page into a text editor or html editor, then save the file as common.css in /skins/common.


 * Anyone got any better advice than this? (NB It's an indictment on the attitute to noobies that no one has answered this question yet... I spent 10 minutes googling and looking around for the answer to this most basic question, and it seems everyone just assumes that noobies like me automatically know this stuff somehow...) 04:11, 14 August 2008


 * Actually, I don't think anyone ever saw the question. Haven't found it, I wonder if it's generated from the files in /skins/common Kylu 04:18, 14 August 2008 (UTC)


 * Because I just spent an hour trying to figure this out myself, I thought I might share my "Duh!" moment. Common.css and common.js are pages in the wiki, itself. Enter "Mediawiki:common.css" into the search field and then edit the resulting page.  Now, if this information is wrong (it worked for me) and somebody knows this, by all means, please respond.  I'm stunned there are so many knowledgeable wiki editors, yet this question remained unanswered. Iceofwolf 08:30, 19 December 2008 (UTC)

Hello all, I came across the same as the posters before me.

My thought was to apply the current mediawiki css to my wiki. mediawiki is running monobook.css somewhere common.css comes into play, so as best I can I am trying to do the same. First I didn't find a file called common.css so eventually I got that if you (as an Admin) search for MediaWiki:Common.css you can create said file. I just copied and pasted the current MediaWiki:Common.css

It saved fine, though I thought it was weird looking, so I ended up installing the Extension:SyntaxHighlight_GeSHi so now the content of common.css and the nice looking highlights makes everything easier to deal with.

To test it so far I Ctrl+F5 on IE8. No change. I am testing with Special:Version because the non common.css tables have a light gray title cell background color, the MediaWiki version has nice blue background colors for the same cells.

The test yielded no change in formatting. Not sure if anyone has given up on this but ill post the rest as soon as I figure it out. Ojmorales0002 03:55, 9 December 2009 (UTC)

Modern skin problems
The following parts of the code are causing small problems (basically causing problems with the colors of the tabs on the top of pages in the Manual, Project, and MediaWiki namespaces as well as their talk namespaces) with the Modern skin (and should be moved to MediaWiki:Monobook.css). FunPika 03:07, 27 June 2008 (UTC)
 * This has been fixed. -- :bdk: 21:53, 31 August 2008 (UTC)

Removal of pre tags
I saw the edit note for this change, where scrollbars (overflow: auto) were removed from pre tags. However, this is an incredibly useful functionality - without it many many pages end up with horizontal scrollbars due to the width of the pre sections. Can you explain the problem with this a little further. Perhaps we can work out a solution that solves both issues? --HappyDog 04:37, 29 October 2008 (UTC) If you don't like horizontal scrollbars, just simply customize your personal skin file, but don't disable the access to other people with global rules. — Danny B. 13:55, 29 October 2008 (UTC)
 * There is no pure CSS solution for this. Some JavaScript utilizing drag handling could probably solve it, though. The issue is: If the  is higher than the viewport and top lines are wider than viewport, you have absolutely no chance to get to the overflowing content of them. Besides inner items of the page with their own scrollbars have their invisible content hardly accessible or even inaccessible.

= 2009 =

Sort of unrelated but...
This is sort of unrelated but i guess it could fit here... You can't just type in into many skin related pages (on the mediawiki software), but is there some easy way of doing that? --Deo Favente 04:31, 21 January 2009 (UTC)

45 errors
Hello, we've noticed that we had a large number of errors in the css-validator 2.1, and more on the French Wikimedia projects (eg: 57 in fr.wp). Is this because of our CSS version 3.0 and do we have a solution to validate our codes? JackPotte 19:02, 25 November 2009 (UTC)
 * I suggest you to post this suggestion on the Support desk --Arseny1992 22:45, 27 November 2009 (UTC)
 * Thank you but it's not yet necessary: we've got actually 0 error by testing the raw CSS page. JackPotte 00:05, 28 November 2009 (UTC)

background-color + :hover
Hello, i am new and cant edit a little problem with the buttons : without  the   doesn't work on   (tested on Firefox 3.5.5 ) Oeil 23:52, 12 December 2009 (UTC)

= 2010 =

CSS Files Causing Slow Login Times
I've been doing some diagnostics on my MediaWiki instance as login times have been really slow. Once users are logged in they can move around just fine. I saw the following from my http logs:

00:00:09.910	1.255	677	303	GET	200	text/html	/wiki/MediaWiki:Common.css 00:00:11.181	0.240	611	6891	GET	200	text/css	/skins/common/shared.css?207 00:00:11.283	0.243	616	5052	GET	200	text/css	/skins/common/commonPrint.css?207 00:00:11.287	0.259	611	24415	GET	200	text/css	/skins/monobook/main.css?207 00:00:11.291	20.219	691	184	GET	200	text/css	/index.php?title=MediaWiki:Common.css&usemsgcache=yes&ctype=text%2Fcss&smaxage=18000&action=raw&maxage=18000 00:00:11.295	54.368	690	231	GET	200	text/css	/index.php?title=MediaWiki:Print.css&usemsgcache=yes&ctype=text%2Fcss&smaxage=18000&action=raw&maxage=18000 00:00:11.299	20.025	693	374	GET	200	text/css	/index.php?title=MediaWiki:Monobook.css&usemsgcache=yes&ctype=text%2Fcss&smaxage=18000&action=raw&maxage=18000 00:00:11.302	47.539	661	256	GET	200	text/css	/index.php?title=-&action=raw&maxage=18000&smaxage=0&ts=20100301191006&gen=css 00:00:11.309	0.482	597	28487	GET	200	application/x-javascript	/skins/common/wikibits.js?207 00:00:11.313	0.481	600	12312	GET	200	application/x-javascript	/extensions/TreeAndMenu/dtree.js 00:00:11.317	0.714	593	4008	GET	200	application/x-javascript	/skins/common/ajax.js?207 00:00:11.320	0.713	598	4701	GET	200	application/x-javascript	/skins/common/ajaxwatch.js?207 00:00:11.323	1.073	598	24407	GET	200	application/x-javascript	/skins/common/mwsuggest.js?207 00:00:11.327	7.351	631	202	GET	200	text/javascript	/index.php?title=-&action=raw&smaxage=0&gen=js&useskin=monobook 00:01:05.700	7.209	632	(4622)	GET	(Cache)	text/css	/index.php?title=MediaWiki:Geshi.css&usemsgcache=yes&action=raw&ctype=text/css&smaxage=18000 (The 2nd column is how many seconds it took for that element to load.)

As you can see all my css files are taking a really long time to load. I don't have a lot of extra code in my Common.css file. I'm also not sure why Print.css and Monobook.css would take so long, as I haven't touched them. Any ideas? --Gkullberg 19:26, 1 March 2010 (UTC)

width of boxes in main page
Could someone change the line  to , so that Languages displays with the same width as the other boxes in the main page? And while you're at it, you could also add, so that the categories box also aligns :) --Waldir 15:41, 18 May 2010 (UTC)
 * Update: Reedy performed the first edit suggested above, but the code had since been rendered obsolete by this change by Happy-melon. MaxSem fixed it. --Waldir 13:55, 16 July 2010 (UTC)

= 2011 =

Clearer comments in CSS code?
Hey hey, just posting a suggestion here. For anyone who's actually going to read and think about this, thanks for your time!

For people like me, who only want to change the colours of their freshly installed Mediawiki around a bit, the following might be helpful: Comments in the CSS file clearly pointing out which slices of code correspond to which part of the Wiki, and maybe a list of or a link to a list of hexadecimal colour codes? I'm sure I could find this all out on the internet somewhere, but I'm having a little trouble doing so, and I'm pretty sure the above shouldn't be much effort for more knowledgeable people and could prove quite helpful for users like me.

And if anyone chooses to act on this suggestion here, thanks a lot for helping us lusers out. Your effort is appreciated.

-92.64.157.75 16:34, 20 September 2011 (UTC)

File location
Where is this file located? In what directory? —The preceding unsigned comment was added by 173.13.231.33 (talk • contribs) 22:01, 1 October 2011‎ (UTC). Please sign your posts with ~ !


 * Common.css is not a file; it lives in the database.  — Edokter  ( talk ) — 08:57, 2 October 2011 (UTC)

I find it odd, this article has instructions on how to refresh my browser, in case I am new to the internet; but it does not have information about how to access or find the code, "common.css", which is what the article is about. "It lives in the database" doesn't help.



Retrieved From
I am trying to suppress the message between the content and the column one. The message in it's entirety is: Retrieved from "http//:www.somedomain.com/index.php?title=Main_Page", depending on the actual page you are on. I have tried looking through the skin's php file also comparing with the monobook skin, also checked here in case I can change within the common.css any ideas's? oh, and why is there not a comprehensive index of terms, that can be used, a full a to z of the mediawiki css commands, or is it just me that can't ind them? RoverOne 08:07, 30 November 2011 (UTC)

=2012=

Add class to hide toc numbering
Please add the following rule to allow per-page suppression of auto-numbering in the TOC:

--Waldir (talk) 19:47, 8 October 2012 (UTC)

= 2013 =

Move to gadget
Does moving Common.css/js to gadget still guarantee correct loading order? As I understand it, userscripts are loaded after common/skin.css.js and before gadgets. — Edokter  ( talk ) — 13:16, 1 January 2013 (UTC)
 * Also, why was Mediawiki:Common.css moved to MediaWiki:Gadget-site.css? Some basic explanation would be helpful. --Rogerhc (talk) 23:13, 9 February 2013 (UTC)
 * What on Earth is going on here? Why is styling loaded through JavaScript? Are you crazy? 58.170.238.184 10:25, 29 May 2013 (UTC)
 * It isn't. Gadget CSS is loaded through a regular stylesheet directive. — Edokter  ( talk ) — 20:50, 29 May 2013 (UTC)
 * Then why is the styling missing when js is disabled? http://i.imgur.com/MUz7wXu.png http://i.imgur.com/peNvkTC.png 58.170.238.184 08:26, 30 May 2013 (UTC)
 * Seems that the enwp-boxes gadget does have a problem, probably because it is hidden. All other styling from this gadget is working without javascript enabled. — Edokter  ( talk ) — 18:21, 30 May 2013 (UTC)
 * I haven't heard any rationale for the move, so if there are no objections, I will move it back in the near future.  09:33, 7 September 2014 (UTC)
 * Allegedly, to benefit from ResourceLoader. Right? --Nemo 15:48, 7 September 2014 (UTC)
 * ^. Helder 17:52, 8 September 2014 (UTC)
 * , Common.css is also loaded as a ResourceLoader module, so what would be the benefit?  21:30, 10 September 2014 (UTC)
 * I don't think the order was ever guaranteed to be that. As far I as know, the way to load something before something else is to use dependencies. Helder 17:52, 8 September 2014 (UTC)
 * I guess I should read bug 27488 again... This is probably discussed there. Helder 18:02, 8 September 2014 (UTC)
 * , My main concern is not dependencies; it is CSS cascading load order. Users need to be able to override CSS in a normal fashion, using regular CSS cascading; one would not need to use dependencies to do that. I will have to check the actual load order of Common.css and gadget css via load.php; if they are indeed reversed, then why break regular work flow?  21:30, 10 September 2014 (UTC)
 * OK, I see the following load order. There are three main calls to load.php: 1. gadgets and core CSS (in that order), 2. site CSS, 3. user CSS. So user CSS is not an issue, but site CSS is now loaded before core CSS. This makes it impossible to override core CSS. Dependencies will not solve this, because you don't know what skin module to depend on. The current dependencies are there for JavaScript only (which is the main reason for the move I suspect), but they can be lazy loaded like is being done on enwiki. Fact is, CSS load order is reversed.  21:56, 10 September 2014 (UTC)

Persian font
Hi. Please add this We have the same on Wikidata and Wikimedia Commons which is added via Persian community consensus of that wikis. ebraminiotalk 10:47, 17 August 2013 (UTC)
 * ✅ Matma Rex (talk) 13:06, 17 August 2013 (UTC)

RTL
Please change it has almost same effect but it will make, it is needed for here flipping for RTL style possible. ebraminiotalk
 * I don't think this is going to work – if it would, then padding would be flipped similarly, and currently it's not. You'll probably need something more explicit, probably using the  class. Matma Rex (talk) 13:13, 17 August 2013 (UTC)
 * Yes. It is right, it will just work on RTL UI. A complete solution I guess needs  and   and both of them need /* @no-flip */ on background-position. ebraminiotalk 15:38, 17 August 2013 (UTC)

Add these css codes for template documentation
Please add /* For template documentation */ .template-documentation { clear: both; margin: 1em 0 0 0; border: 1px solid #aaa; background-color: #ecfcf4; padding: 1em; } So that the template documentation would like nice and better. This is an updated code part of the code is already on this page 86.135.252.13 20:39, 11 March 2014 (UTC)

Remove hack?
Since 26204 was marked as fixed, this part of the code should not be needed anymore. Helder.wiki 01:59, 1 July 2014 (UTC)
 * Removed.  21:31, 3 July 2014 (UTC)

Add css for mbox, fmbox, ambox, ombox and other
Hi please add this css Currently the templates are broken please see https://www.mediawiki.org/wiki/MediaWiki_1.26 which use to show boxes with the text inside now nothing. Paladox2017 (talk) 16:57, 10 August 2015 (UTC)
 * I see no broken templates, and we generally have no use for all this ambox code here.  20:30, 10 August 2015 (UTC)

TOCLIMIT doc
This commentː /* * Allow limiting of which header levels are shown in a TOC; * &lt;div class="toclimit-3">, for instance, will limit to * showing ==headings== and ===headings=== but no further. * Used in Template:TOC */

Does not appear to be true anymore. Is it dependent on a particular addon? There is also no "templateːTOC" in the search pages on this wiki.

Why deleted?
Please, tell why this page has been deleted, I don't understand why.

= 2019 =

Add plainlist
Please add this code (copied from meta-wiki). It should be added just after the  line. It will help to style sidebar navtemplates without visible bulletpoints.

/* Unbulleted lists */ .plainlist ul { line-height: inherit; list-style: none none; margin: 0; } .plainlist ul li { margin-bottom: 0; }

Thank you! Quiddity (WMF) (talk) 17:52, 29 March 2019 (UTC)
 * ✅ --wargo (talk) 18:25, 29 March 2019 (UTC)

Remove .note styles
I’ve moved .note-* styles (lines 321—353) to Template:Note/styles.css, so they can be removed from here. The .tip-* variants seem to be unused, but please double check me before removing them as well. —Tacsipacsi (talk) 15:59, 10 June 2019 (UTC)
 * Any of you? —Tacsipacsi (talk) 22:06, 15 June 2019 (UTC)
 * . Done. Thanks. Can you do this for other templates too? Ladsgroup (talk) 01:33, 16 June 2019 (UTC)
 * (Sorry for the quite late reply.) Unfortunately I found no other style that would be used by a single template—some are used by several templates, others are even in non-template pages’ source code. This makes moving them to TemplateStyles much harder. (Preferably a new template should be created that contains the common markup and the reference to the TemplateStyles subpage, but this takes a lot time, so I’ll probably do it when I’ll have tons of free time. Which may never happen…) —Tacsipacsi (talk) 15:30, 23 April 2020 (UTC)

Mainpage Logo
Hi! Is here the solution to change Wiki Logo in Main Page (left side) for our tt.wikipedia.org? We want to use File:Tatar Wikipedia holiday logo 1.png and File:Tatar Wikipedia holiday logo 2.png temporarily. --Derslek (talk) 20:15, 8 December 2019 (UTC)
 * Yes, there is: append  (with   replaced to the URL of the logo) to MediaWiki:Common.css. Pay attention to use an appropriately sized logo (the thumbnail should not be larger than 160×160px) with transparent background, e.g.  . Larger images get cropped, while images with non-transparent background look awful on the gradient of the interface. (Also, your wiki uses high-definition image on larger screens, so you have to repeat the two   rules at the bottom as well, with the URLs changed appropriately, i.e. pointing to the holiday image, but with larger resolution.) —Tacsipacsi (talk) 16:09, 15 December 2019 (UTC)
 * Please do not encourage people do to this hack rather than a proper change, it damages the site performance for all readers. Jdforrester (WMF) (talk) 18:48, 15 December 2019 (UTC)
 * Hey there, to ask for this, you should file a Phabricator task; I've filed T240797 for you, but I don't understand. Can you reply there? Thanks. Jdforrester (WMF) (talk) 18:48, 15 December 2019 (UTC)

Would you mind explaining what damage it causes, instead of just shouting at me without giving any evidence? It’s a quite common practice, and I don’t see any performance drawbacks; the “proper” way, however, wastes everyone’s time (devs doing and undoing the change, community formally voting on the absolutely uncontroversial change, which may be a widely accepted practice done every now and then on the wiki, volunteers preparing the vote, notifying people filling and forms on Phabricator etc.). Not only users’ load microseconds count! By the way, why would this be a hack at all? MediaWiki itself sets exactly the same CSS rule, differing only in image path. —Tacsipacsi (talk) 22:15, 21 December 2019 (UTC)
 * Sorry, I'm lost. In what way do you think bloating the site by ~100KiB (1x+1.5x+2x) of binary (uncompressible) downloads which are then rendered but hidden for every reader, bypassing the documented way to do this properly, isn't a hack? Jdforrester (WMF) (talk) 18:42, 6 January 2020 (UTC)
 * Thank you for the explanation of this method’s costs. However, the “proper”, documented way also has costs: people’s time. It takes wiki several community members’ time to make a formal vote, which has a result obvious to outsiders (people who fulfill site requests), it takes a community member’s time to actually create the Phabricator task, it takes a sysadmin’s time to fulfill it, it takes a community member’s time again to remind when the logo should be reverted, it takes a sysadmin’s time again to revert the change. It has much higher one-time costs, which are of course outweighed by the win at load time when the change is permanent (or at least long-term temporary), but I think these costs outweigh the wins when the change is short-term (I think the change discussed here would have lasted no more than one or two weeks).
 * By the way, I checked a few wikis’ CSS, and the logo set in InitialiseSettings.php is always a  rule in CSS, which means it’s basically a race condition that the 100% version gets loaded at all—if the browser processes the override before attempting to load the normal (InitialiseSettings.php-based) logo, it won’t load the unused one at all (and in no case will it attempt to load the larger-resolution ones unless they are actually used). I loaded zh-min-nan:Thâu-ia̍h several times in Firefox, and it never loaded https://zh-min-nan.wikipedia.org/static/images/project-logos/zh_min_nanwiki.png, only https://upload.wikimedia.org/wikipedia/commons/e/e0/Wikipedia-logo-v2-zh-min-nan-300000.svg. —Tacsipacsi (talk) 15:19, 23 April 2020 (UTC)