Hi. Indeed, the CSS format does not permit use of @import
anywhere other than at the start of a stylesheet. However, the guruantees we provide for batching and ordering stylesheet modules requires exactly that (in most cases) we place it somewhere later in the response.
In ResourceLoader we have a legacy exception for the "user" (personal user css) and "site" (site-wide Common.css) modules which historically are unable to register their subfiles as native. The exception is that when we encounter a later chunk, we split it out into a new request and/or flush the chunk as its own <style>
element.
For all other modules (MW core, extensions, and gadgets) it is expected that code is loaded natively for optimium performance as we do not want the visual rendering of articles to be delayed by late-discovered additional requests, especially requests to other domains.
The type
option for gadgets (docs) can switch between pure "styles" and "general". The main benefit of "styles" is that it loads immediately and before the page is visually rendered. However, this immediate-ness is contradicted when importing files from other wiki. The browser does not know about these files until after all the styles have arrived. Delaying rendering at this point is slow.
Your options are:
- Make it a locally cached and optimised gadget, by copying the page content as well. This creates fast page views and no delays of dark mode.
- Alternatively, you can set
type=general
. I tried this in jawiki rev 90881097 and confirmed that this "works" in so far that it makes the page render exactly as fast as if dark mode was not there, but then dark mode arrives at the same time as it would if we were to delay rendering for cross-domain styles import. Despite being faster, this way feels slower because we first see the fast page rendering and only then the dark mode.
There are ways to support @import
with workarounds in our software that create complicated ways of loading stylesheets, that are difficult to debug and understand. I have choses in the past not to support this, and instead invest the cost in making everything else faster and simpler. The first option would be my recommendation in today's possibilities.
There is a third option, which is to develop the code as an extension and seek deployment (or in the future, "global gadgets", phab:T22153).