Page MenuHomePhabricator

Allow @import of local sanitised CSS files into other sanitised CSS files on same wiki
Open, Needs TriagePublicFeature


Feature summary:

Utilise a single local CSS file within other files, without needing to replicate its content; nor have the file centrally lodged in wiki's common.js

Steps to reproduce (a list of clear steps to create the situation that made you report this, including full links if applicable):
Use case(s) (describe the actual underlying problem which you want to solve, and not only a solution):

Recreating the same CSS across 70 files is not only time-consuming in the first instance, but also if one needs to update the code that it needs to be replicated across the remainder of the css files of the series of works.

Putting the respective cssof multiple works into common.js is not particularly a sustainable approach, and will lead to (further?) CSS bloat.

What would be useful is if we were able to set up one of the Index:...css files to have the css code for the work, and then allow a local import of that file into the respective Index: files of the series. Still a little time-consuming, though not overburdening at an intial set up time, and could be bot'd at the original configuration.

I m only looking for the import to be of another css-sanitized file, not of css files from anywhere else on the wiki

Event Timeline

Billinghurst renamed this task from Allow @import of local css files in sanitised CSS to Allow @import of local sanitised CSS files into other sanitised CSS files on same wiki.Jun 20 2021, 3:46 AM
Billinghurst updated the task description. (Show Details)

This was discussed in passing in T155813#3022550. There are two options:

  • make @import (or something custom that can be used instead) transclude the referenced styles (like @import "foo.less"; works in LESS);
  • transform @import "Template:Foo/styles.css"; into something like @import ""; where action=ts-import works like action=raw except it aborts if the content is not sanitized CSS.

The second is complicated and has poor performance characteristics so that's a non-starter, I think. The first seems doable although it would mean the importing stylesheet needs to be invalidated if the imported stylesheet changes, but I think normal LinksUpdate would take care of that. Still it seems like a lot of effort for something that can already be handled by normal template transclusion mechanics (use separate stylesheets and an intermediary template to group them together).

Still it seems like a lot of effort for something that can already be handled by normal template transclusion mechanics (use separate stylesheets and an intermediary template to group them together).

For the new Index-specific CSS it would certainly be less friction to allow an @import (or whatever the syntax) from Index:Foo/styles.css which enables "composition" of stylesheet. Especially useful for multi-volume works where they are likely to share most general formatting.

The alternative is to add a way for Indexes to specify a list of styles to import (which was my original idea in T215165, but that makes the PRP implementation a bit more complex for the simple case (one style/index).

… Still it seems like a lot of effort for something that can already be handled by normal template transclusion mechanics (use separate stylesheets and an intermediary template to group them together).

Templates are not a viable workaround here since the stylesheets in question are (and must be) automatically applied by Proofread Page. The stylesheet lives in a fixed subpage of a page in the Index: namespace, is automatically applied to all the associated pages in the Page: namespace, and ditto when these are transcluded (transclusion is mediated through PRP, not raw MW transclusion) into mainspace for presentation. The only viable approach (from a user perspective) I see is something that has roughly the characteristics of @import "Index:Foo/styles.css";.

Faking this entirely in PRP could certainly be made to work, but architecturally it'd be a hack and a layering violation (the functionality belongs in TemplateStyles, of which PRP is just a client). If it could be implemented in a way that also benefits the (more obscure) few cases where it would be convenient in general TemplateStyles use that would be good too (@import is the normal way to compose CSS, so conceptually cleaner than multiple <templatestyles> tags in the template layer), but as that use case has workarounds that's less pressing.

By the way, it occurs to me that we don't actually need this functionality to literally be CSS @import. Something with the semantics of cpp's #include would work equally well for our purposes. In effect, a santized-css specific way to transclude another santized-css page.

If it is easier to bolt on such a semi-transclusion than to enable real CSS @import with the security, performance, and architecture issues resolved... that could be a viable alternative approach.

For the Wikisource use case (the one that has no workaround), the important part is being able to reuse (sanitized-)CSS code without trying to keep snippets in sync across ~50+ pages. Any mechanism that lets us put some kind of magic syntax into a santized-css page that says "insert the common styles found in [[sanitized-css wikipage]] here" would solve it.

That being said, making the syntax CSS @import, but implementing it in MediaWiki (vs. the browser), would seem to be more discoverable and reuse existing skillsets.

Another alternative is exposing some subset of something LESS-ish to templates (why can't I find the task for that one? I was sure it existed.). That would make solving more problems easier too, such as letting templates provide parameters (like a color value) to stylesheets.

A concrete example of the use case on Wikisource:

The 1911 edition of the Encyclopedia Britannica is 29 volumes. We have scans of it hosted in 29 separate DjVu files on Commons, each with a Proofread Page-managed index in the Index: namespace. For each physical page in the scan there is a corresponding page in the Page: namespace containing the transcribed text (10–20k total wikipages, I'm guessing). The Page: namespace pages are then transcluded into mainspace pages corresponding to a complete unit of text (here it's encyclopedia entries, for fiction it'll be chapters, etc.), using Proofread Page-mediated transclusion.

Proofread Page automatically loads Index:Foo.djvu/styles.css for each of those Page: namespace pages and for each mainspace page where those pages are transcluded.

We have historically used a combination of templates and Common.css styles to do the necessary formatting. With the addition of this per-index style support in Proofread Page we are now able to move a lot of code out of Common.css and into per-index styles. For single-volume books this works great.

But for 29 volumes it's simply not feasible to cut&paste snippets to keep them in sync, and wrapping this in a template that just loads a templatestyles stylesheet is a no-go for the 10–20k individual pages (and though the numbers are smaller a dictionary or encyclopedia can still have mainspace pages in the thousands).

We could cheat our way around it by turning the per-index style page a redirect to a central stylesheet, but 1) that requires futzing with changing content models and other obscure admin-only stuff and 2) it forces every little custom tweak applicable to a single page into the common stylesheet and has to get loaded for every single one of those 10–20k pages (i.e. Common.css in miniature). It very quickly becomes unsustainable.

With something @import-ish we could give each of those 29 volumes its own per-index stylesheet for local tweaks, but keep all the common stuff in one place and @import that into each volume.

And while the 1911 Encyclopedia Britannica is certainly among the larger works, it's not really an outlier. There are many of these reference works that clock in around this end of the scale, and these are also often among those most interesting for citing on Wikipedia or for random readers (i.e. we have a disproportionate number of works in this category).