So, back in 2018, the method of loading CSS was changed to use load.php and improved so that imports could be performed on any CSS page so long as they were at the top of that page.
I am currently helping someone change the font on their wiki (here). In the course of doing so, it appears that the change to imports has been reverted. In other words, it once again matters which page imports are on.
Is this a recent change or did it happen a while ago and I just didn't notice? It seems to impact both site and personal CSS; as did the previous change.
Yes. It is happening with personal CSS as well. Also, we tried import statements on both pages and only the one on Common.css would work. If it was the 2014 change, the reverse would be true; Wikia.css would work but Common.css would not.
Both stylesheets work for things other than imports. Only imports are having an issue. Imports at the top of Common.css work but those on top of Wikia.css do not. There is a similar issue with personal CSS as well. Perhaps it isn't exactly a reversion but the effective behavior is as if the 2018 change to imports was undone.
Its due to how wikia loads css and js (and has been for a long time now iirc). The site/user css/js pages (Common and Wikia (and Print if its css)) are combined into one file, but they're not merged, just put one after the other (same with user css/js, which puts global.css/js at the start), so sometimes the imports don't end up at the start of the file, hence why they don't appear to be working.
(in the above urls, you put the wiki you want as the start of the url, debug=true is for making it readable (it also bypasses cache, so you can use it to see if your changes work), modules=site or modules=user are telling it if you want to load site or user css/js, only=styles and only=scipts are telling it if you want to load css or js, and if you're loading user css/js, you need user=Example to tell it what user's js/css you want. You can load both site and user js/css at once by use modules=user|site (you'll still need the user paramter), it will put the user css/js above the site css/js.)
Yes, that is the way it used to be. However, as noted in the other thread, that was changed around April 2018. It is possible the reversion happened a while ago but I didn't notice it until today/yesterday. Here is the approximate timeline as far as I am aware.
Behavior of Common.css changes
Older wikis may request an "update" to the new bahvior
CSS loading is switched to load.php
Import statements can now work on any CSS page regardless of what is on other CSS pages
There were no changes to loading of CSS in the last few years.
Yes, MediaWiki:Common.css was disabled on wikis created before July 2014 so its contents do not break Oasis.
I don't see what you mean by "CSS loading is switched to load.php". It was always loaded via load.php, also known as ResourceLoader.
There was a change to remove the default contents of MediaWiki:Common.css (probably around April 2018) so @imports could be placed in MediaWiki:Wikia.css. This is because, on wikis with MediaWiki:Common.css enabled, ResourceLoader loads both MediaWiki:Common.css and MediaWiki:Wikia.css, then minifies and concatenates them together. As @import statements can only work when placed on top of the concatenated (and minified) stylesheets (and this was always the case), this means:
If MediaWiki:Common.css isn't enabled, you will have to place your imports on MediaWiki:Wikia.css.
If there are contents of your MediaWiki:Common.css other than imports, you will have to place your imports at the top of it.
Regardless of what CSS page are you placing imports on, you will have to place them on the top.
Well, there was definitely more of a change in 2018 than just removing the default contents. Prior to the change, I would see which sheet the CSS was from. For instance, using "inspect" on a page element to view CSS, you could see the sources distinctly as "Common.css" or "Wikia.css". After the change, they both showed as "load.php?...". This was the change that I noticed and asked about. In his reply (at the time), Fngplg brought up the change to how @import was being treated.
I don't know. Maybe it was just a change in how ResourceLoader was being used but there was definitely more to the change than just removing default content from Common.css. Anyways, I have sent this question to staff so I guess I'll see what they have to say sometime next week.
It could be. As I have said on multiple other occasions, you are much more familiar with the back end than I am. However, I still stand by my statement about @import behavior. I may not know exactly what changed but as far as I can tell something definitely did.
Okay, well apparently I am going crazy. I just finished talking to Fngplg and he said that his comments in that discussion were the result of confusing what appeared to be the case at a quick glance and what was actually changing. He says he realized his mistake after but apparently he never posted that update to the thread.