Page MenuHomePhabricator

Merge Extension:Theme into core
Open, Needs TriagePublic

Description

This is a proposal to merge the Theme extension into MediaWiki core in order to generally make it a lot more effective and useful. For a more thorough background on what MediaWiki themes are and the context for their use, please see the writeup on mw.org. This task describes the technical aspects, on the assumption we can all agree that we want to support things like Night mode and accessibility options in a way that doesn't constantly break and isn't purely js-based and/or done by adding a bunch of extra css on top of the existing styles. (Does anyone disagree with that?)

Problem

Extension:Theme enables setting different variants (typically colour schemes, such as Night mode or the official colours of a project) for skins, and represents the most effective, efficient extant implementation we have for such functionality (the above writeup on mw.org includes many links to less effective implementations).

As an extension, however, it has certain limitations:

  • All we can really do is define new modules, typically to add stylesheets on top of the existing stylesheets.
  • We can't feasibly use SkinStyles (loading component-specific styles only on page(s) the components are on) extending ResourceLoader itself to handle themes, so we basically just have to load all theme styles on all pages.
  • While it is technically possible to create variable-based themes, it's super hacky and basically just requires including all the actual styles from the variables files, instead of visa versa. And any theme variables again cannot be reused in SkinStyles. (example)
  • Developers tend to be resistant to making their products depend on other products, and we've already wound up with a bunch of half-forks, generally out of date and incomplete, of the extension living in various skins so that they don't require deploying an extra extension to make use of the full features.

Solution

We should be moving toward using variable-based themes, as this is both more efficient to render and download, and also a lot easier to actually make as a developer. Because of the widespread desire for theme support and that some of this requires changing how ResourceLoader handles skin modules, it is simply not feasible to continue to support this in an extension.

I propose three things:

1. Merge the current logic of Extension:Theme into core (patch)

This does the following:

  • Add the basic support for defining the themes a skin supports (adding ThemeModules)
  • Enable the settings for users/sysadmins to select themes, the ?usetheme url param for testing, etc
  • Add the basic logic of adding theme modules, which will be loaded along with the other default modules (currently this is all the extension does and isn't a good solution in general, but we will still need this even with proper variable support regardless - sometimes, you gotta override/add some extra styles for a particular theme to fully work, no matter how good your variables are)

2. Add support to ResourceLoader to handle skin modules and theme modules together

Allow ResourceModule definitions to define what theme(s) their styles are for, and only use those styles if on that theme. Any styles where this is not set will be assumed to be for all themes. Same thing for adding to ResourceModuleSkinStyles - support adding to a module, but only for the given theme for the given skin.

So one might define a module like so:

"skins.skinwithnighttheme": {
	"targets": [ "desktop", "mobile" ],
	"styles": {
		"resources/main.css": {
			"media": "screen"
		},
		"resources/main-night.css": {
			"media": "screen",
			"theme": "night"
		},
		...
	}
},

Where the main-night.css is loaded after the main.css as part of the same module iff the night theme is selected.

This would be doing effectively the same thing as Theme does currently, but more cleanly. However, changing to this approach will break backwards compatibility in terms of how we define themes and their stylesheets (currently we create separate modules entirely for each theme, which will no longer be necessary as such), so all current skins supporting themes will need to be updated, which we plan to do concurrently.

Again, this will still be required even after adding #3, as not all themes will be possible by (only) changing variables. For instance, one might make a theme to change all the fonts to be bigger, higher contrast, etc: while the main part would be done by changing the fonts and font-sizes in the variables file, it will likely also require adjusting/specifying some other changes as well to fully work, such as line heights, paddings and border positions for certain interface elements, and things like that that cannot necessarily be set/calculated from the variables themselves.

3. Add explicit support for theme variables, and push it as the primary method of implementing a theme

Basically, we add some way such that when we import the skin's default variables.less file, we can also import the automatically determined current theme-variables file.

So perhaps we do

"ThemeModules": {
	"skinwithnighttheme": [
		"night": {
			"variables": "resources/themes/night.less"
		},
		...
	]
},

in the skin.json, and this gets passed into a less variable we then use to load the file with the variables:

@import resources/variables.less // or whatever we called the main one
@import @theme-variables;

So then any variables in the second one override the first, but it doesn't require the second having all of them, either. And if no theme is selected or the theme doesn't actually have any variables (who knows, maybe one of the themes just rotates the entire page upside down or something; you don't need variables for that), just send it an empty file for the second.

Notes

  1. If none of this makes sense, please look at how current skins define ResourceModules (example: any), ThemeModules (example: Bouquet), and ResourceModuleSkinStyles (example: MonoBook) in their skin.json; and tend to import a variables.less file in their specific stylesheets (example: Timeless).
  2. The suggestions for #2 and #3 are generally based on what we currently define in skin.json etc and what we could probably do with a ResourceLoaderVariableModule, but are largely theoretical. The Theme extension itself, however, already exists and is mostly solid in terms of what it's doing; it's just not doing nearly enough.
  3. The original RfC can be found on mw.org. Some discussion has also occurred on the related talk page onwiki.

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
matmarex set Security to None.Jan 7 2016, 11:49 PM
This comment was removed by SamanthaNguyen.
SamanthaNguyen renamed this task from Implement Extension:Theme in core with Less variable support to Implement Extension:Theme in core.Apr 15 2017, 7:02 PM
SamanthaNguyen updated the task description. (Show Details)
SamanthaNguyen added a project: Technical-Debt.

Splitting off, there's a separate ticket for supporting Less on-wiki at T56864.

Change 465451 had a related patch set uploaded (by Jack Phoenix; owner: Jack Phoenix):
[mediawiki/core@master] [WIP][DNM] Merge the Theme extension into core

https://gerrit.wikimedia.org/r/465451

Isarra updated the task description. (Show Details)
Isarra renamed this task from Implement Extension:Theme in core to Merge Extension:Theme into core.Dec 6 2018, 1:14 AM
mobrovac updated the task description. (Show Details)
mobrovac moved this task from Inbox to Watching on the TechCom board.
mobrovac added a subscriber: mobrovac.

I updated the task description to reflect the fact that the canonical place for this RfC is its MW page.

mobrovac moved this task from Inbox to Under discussion on the TechCom-RFC board.Dec 12 2018, 1:46 PM
Isarra updated the task description. (Show Details)Feb 7 2019, 12:52 PM

Perhaps this better explains what we actually want to do here? I don't even know how to properly explain any of this anymore.

Basically this RfC is really just us asking if there's any particular reason not to merge the associated patch, once fully tested and such, because it's slightly larger than the usual change.

Jdforrester-WMF added a subscriber: Jdforrester-WMF.

I've copy-pasted the content from MW.org per the request of TechCom. Not linked or re-formatted except where strictly necessary; copy-edits welcome.

Isarra added a comment.Feb 8 2019, 7:33 AM

The links are kind of important.

Tgr updated the task description. (Show Details)Feb 17 2019, 6:51 AM
Tgr added a subscriber: Tgr.Feb 17 2019, 7:03 AM

Linkified.

It's not clear to me whether this is about providing a way for skins to define their own subthemes (so if, say, the Vector maintainers want a night mode, they don't have to worry about coming up with their own settings widget, siteinfo API extension etc, and maybe extensions which provide skin overrides or Vector can make them theme-specific), or about providing a way to define alternative themes outside of the skin (so if I want Vector but dark, I can write Skin:VectorNightMode which overrides a bunch of things in Vector)? The patch seems to be leaning towards the latter.

In the first case, this sounds like a commonsense change to core, except there is no point in exposing the theme array as a configuration variable; skins can just declare their skins statically. Also a lot of the examples in the task description would not be relevant (e.g. this would not replace gadgets).

In the second case, as others have said it sounds like a maintenance nightmare waiting to happen, unless skins can provide a well-defined restricted interface that's available to themes for tweaking (a set of LESS variables being the obvious implementation).

It's not clear to me whether this is about providing a way for skins to define their own subthemes (so if, say, the Vector maintainers want a night mode, they don't have to worry about coming up with their own settings widget, siteinfo API extension etc, and maybe extensions which provide skin overrides or Vector can make them theme-specific)

This is what we're proposing, yes.

or about providing a way to define alternative themes outside of the skin (so if I want Vector but dark, I can write Skin:VectorNightMode which overrides a bunch of things in Vector)? The patch seems to be leaning towards the latter.

This is also required for backward compatibility, as currently it is the only thing we have - eventually we'll want to migrate most of it to be the former only, or defined specifically on-wiki or such, but that will require massive overhauls of not just mw core, but also and especially all of the skins themselves.

In the first case, this sounds like a commonsense change to core, except there is no point in exposing the theme array as a configuration variable; skins can just declare their skins statically.

Why not? One of the main use cases here is skin developers creating a variant of an existing skin instead of an entire new skin. Don't we need to expose the theme array so they can actually register these new variants as available and selectable themes?

Also a lot of the examples in the task description would not be relevant (e.g. this would not replace gadgets).

How is it not relevant that it will provide a neater way to do something that is currently sometimes done via gadgets?

In the second case, as others have said it sounds like a maintenance nightmare waiting to happen, unless skins can provide a well-defined restricted interface that's available to themes for tweaking (a set of LESS variables being the obvious implementation).

You're right, this is a maintenance nightmare, except it's not waiting to happen, it's where we are currently. Only it's even worse than you seem to be imagining, because we're dealing with many different, usually unmaintained, different implementations of the base logic as well, because there is no standard.

Tgr added a comment.Feb 18 2019, 8:44 PM

This is also required for backward compatibility, as currently it is the only thing we have - eventually we'll want to migrate most of it to be the former only, or defined specifically on-wiki or such, but that will require massive overhauls of not just mw core, but also and especially all of the skins themselves.

You mean, backwards compatibility with the Theme extension? Just leave the extension as it is for now, and remove themes from it when they are migrated into the parent skin's repository (assuming the skin maintainers are willing to take ownership).

Why not? One of the main use cases here is skin developers creating a variant of an existing skin instead of an entire new skin.

What I'm saying is, you have two different use cases here (themes added in the main skin's code vs. themes added externally) with somewhat different technical requirements. IMO it would help to set them apart more clearly as IMO one of them is uncontroversial and the other, not so much.

You're right, this is a maintenance nightmare, except it's not waiting to happen, it's where we are currently. Only it's even worse than you seem to be imagining, because we're dealing with many different, usually unmaintained, different implementations of the base logic as well, because there is no standard.

If people install unmaintained or unmaintainable skins and screw up their sites, that's their problem. (We don't always do a good job of warning people what's unmaintained, but that's a whole another discussion.) I'm more wary of creating an expectation that it's a skin maintainer's responsibility to not make any changes that would break other skins built on top of theirs, which I don't think is happening currently, but wouldn't be an unreasonable expectation for a core feature.

Perhaps some history of how skins are will help clarify things here:

  1. Prior to 2014, skins as skins fell into two categories: core skins, and non-core skins. This wouldn't necessarily have been an issue, except this was well prior to MediaWiki's current registration system, and because the core skins were simply directly integrated into MediaWiki itself (skin messages were in the main mw messages directory, rendering functions were scattered across various skinning and output classes and were often skin-specific), they were not even using the same interfaces as the non-core skins to begin with. This caused a few rather significant problems:
    1. Non-core skins simply couldn't do as much as core skins because the interfaces they had available didn't provide the same functionality.
    2. Having separate interfaces for core and non-core skins resulted in the non-core ones going generally unmaintained because they were considered secondary to the actual core skins.
    3. Core skins were much more difficult to develop on and maintain because of the barrier to entry, requiring core access and knowledge of where each individual skin kept its parts, as they weren't exactly consistent.
    4. The quantity of available core skins was limited, not just because of the higher barrier to entry, but also just because we really wouldn't want to have that many default options to begin with. Indeed, the latter still applies - we only package five or so skins with the MediaWiki release tarballs, despite there being many more available that third-parties could potentially use - but now it's also much easier to drop in any other as well. The included ones are merely the defaults, whereas before they were at times the only viable options.
  2. In 2018, I rewrote the PHP source of the MonoBook skin, maintaining consistent HTML output so as to avoid messing anything up user-side. Unfortunately, this still broke the Modern skin, which directly depended on MonoBook's template in order to generate the HTML. Given that Modern was essentially a retheme of MonoBook (same HTML, different CSS), this clearly demonstrates the issues with this approach, regardless of how exactly it's done:
    1. By depending on another skin directly, such as by extending the template class (less common, but what Modern did): new skin remains largely stable with core, and inherits most updates to continue working with core that are implemented in the parent, unless they change the structure of the class itself. Does require said other skin to be installed. Completely breaks if the parent structure ever changes.
    2. By forking another skin (more common; possibly even the most common way to create a new skin currently): new skin does not continue to depend on the original skin; does not break when the original skin changes its structure. Requires ongoing maintenance to continue working with core updates, due to constant breaking changes in core, and otherwise just breaks.

For 1, this shows a lot of what we want to avoid doing here, but also the importance of properly supporting extensibility - one of the main problems with the core skins was the lack of a consistent system behind them that could be used by all skins, and as a result not only did the core skins suffer, third parties could also not effectively make their own (and when they did, they were really prone to breaking - yes, even worse than currently), which was a bit of a problem since generally speaking most sites actually don't want to look like Wikipedia. They have their own brands, and stuff.

2 demonstrates one of the main use cases here - yes, everyone wants accessibility options and night mode and all that, but when it comes to third-party projects, most of the time what they actually want is more to just change the base colours of a skin to, well, be their colours, than make a new one. To make an existing skin follow their own branding. So providing a more stable way of going about that means they're much less likely to get blocked on some old mw missing all the security updates because they lack the time or know-how to maintain a skin themselves that shouldn't even be a separate skin in the first place.

Isarra updated the task description. (Show Details)Feb 19 2019, 11:15 AM
Isarra updated the task description. (Show Details)Feb 19 2019, 11:29 AM
Bawolff added a subscriber: Bawolff.EditedFeb 19 2019, 11:49 AM

So summarizing a discussion I had with @Isarra on irc [I am not a skin expert. I may have misunderstood some of the finer points here. If I make mistakes or say something stupid here, that's my bad]:

Also a lot of the examples in the task description would not be relevant (e.g. this would not replace gadgets).

its not meant to replace gadgets in the sense of allowing user defined styling. The gadget examples are listed to show demand for a feature to make skin variants. This is a proposed API to make skin variants that is believed to be a much better fit than gadgets are for making skin variants, thus replacing a current usage of the gadgets interface with something else.


So its expected there would be two types of skin variants (themes):

  • (for lack of a better word) "core" variants which are bundled with the skin, and developed along side it. For example a "night mode" version of Vector. It is expected such themes would have wide applicability
  • External themes. These are not developed alongside the skin, but would be installed via separate extensions and have a much more limited audiance. For example, if you use mediawiki as part of your company website, maybe you write a theme to take monobook and replace the colours with your corporate colours, and otherwise add branding. Perhaps you want to do something weird that makes sense to your community but monobook devs wouldn't want to bundle for being too special-purpose. For example, maybe you want pink-coloured monobook. Or whatever.

@Tgr has pointed out that there are some concerns about stability expectations around the theme interface. This may result in making it difficult to refactor skins as people would worry about breaking theme's which could potentially do anything. I believe (not 100% sure on this) that the stability contract that @Isarra envisions for this feature is that the interface is unstable (I mean unstable as in the skin can change to break themes. The theming api itself remains stable). At best developers make a best effort to not screw over theme developers. (This is similar to core's existing deprecation policy in practise). While in an ideal world we would have a stable interface, in practise it seems like it would be impossible to make a stable interface that is also flexible enough to meet the usecase of this feature. In particular, even though the ideal would be to have only a set of less variables exposed, there are no existing skins that have flexible enough less variables to make this work. @Isarra tried to design "timeless" so it would work in this fashion, but ultimately using less variables for themeing that skin was insufficient and themes for it has to use css overrides. Furthermore, @Isarra believes that the existing framework (or lack thereof) of people forking skins, using css gadgets, etc is very difficult to maintain; the wide interface provided by themes, while not ideal, would nonetheless be a major improvement on the maintainability front.

So its expected there would be two types of skin variants (themes): ...

This. And the two types of themes must be implemented the same way, using the same interfaces, else we risk a repeat of the mess with the core vs non-core skins back in the day. The only difference can be where they are defined. (So we want to support themes being easily moved or forked from one group to the other, and same packaging regardless of type)

It's not currently anyone's expectation that anything be stable with skins, to my knowledge, but most skin maintainers themselves do indeed try to maintain considerable output consistency for the sake of supporting user-side customisation (scripts and styles) as well as not messing up extension expectations. And even if they do wildly change a skin out from under an existing theme, it being a theme still limits the breakage to be some css needing rules updated instead of mw fatal erroring.

Seriously. The status quo is fatal errors. It sucks.

Change 465451 had a related patch set uploaded (by Jack Phoenix; owner: Jack Phoenix):
[mediawiki/core@master] [WIP][DNM] Merge the Theme extension into core

https://gerrit.wikimedia.org/r/465451

Hi, how do we move this forward, in any direction?

At this point, I would really like to see the associated patch merged, once fully tested and any specific implementation issues are resolved. While I am hoping we'll be able to replace the specific code and logic as part of T217158 later, it would still be incredibly useful right now to be able to establish better practices in terms of existing skins and resolve the current theme code fragmentation where it's been half-merged into a few of them (and would even help with any eventual migration to a better system later just because they'd be less of a mess to begin with at that point). I also firmly believe we can benefit greatly from having a framework in place for testing and implementing the skin variants our users on Wikimedia projects have been asking for for years, because in order to do this effectively, we need something better than what we have. (See for reference: all the past attempts that eventually just broke because they were all done as hacks on top of the skins, as opposed to built-into the architecture of the skin itself.) I have been meaning to showcase such functionality in Timeless pretty much since the beginning of the project, but without any backend support, it has proven completely infeasible to do so in any way that is maintainable.

Are there any specific objections to merging the patch, on a theoretical level or with specific code concerns? Does this lack of response mean we can move forward with this, or what?

Jc86035 added a subscriber: Jc86035.Apr 8 2019, 3:55 PM

I'm not sure if I'm supposed to do that (in fact I'm pretty sure I was told I wasn't), but maybe that will get this to move forward?

Also I gotta rewrite this, and phabricator is incredibly difficult to edit with large amounts of text, so, er, I'm going to have to move the bulk of the background back to the wiki page...

Isarra updated the task description. (Show Details)Jul 3 2019, 1:06 AM
Isarra added a comment.Jul 3 2019, 1:55 AM

Should now be a lot more specific about what we actually want to do here.

  • Does anyone disagree with the premise (support simple variants of skins in a resource-friendly and stable way)?
  • Does anyone disagree with the proposed solution?
Isarra updated the task description. (Show Details)Jul 3 2019, 7:50 PM
Magwac awarded a token.Jul 3 2019, 8:19 PM
Magwac added a subscriber: Magwac.

TechCom is hosting an IRC meeting on this in #wikimedia-office on July 24th at 21:00 UTC/23:00 CEST/14:00 PDT

ashley updated the task description. (Show Details)Jul 22 2019, 4:29 PM

@Isarra would you be able to make the meeting this Wednesday? (July 24th at 21:00 UTC/23:00 CEST/14:00 PDT)

Yeah, we'll be there. I had a momentary panic this morning because I mixed up the days, but we're good.

Isarra updated the task description. (Show Details)Jul 22 2019, 8:15 PM

Let's put these example links on the mw.org page. It lacks... much of any. >.>

Some general info on use cases:

  • We probably do need to be able to apply multiple themes. This shouldn't require too much in terms of interface changes, but we might want to declare... types of themes, or stuff. Like overhauls vs accessibility settings, layout and colour changes vs just colours, and then have some simple checks to see what to even allow. In particular we'll need to allow more than one of the accessibility ones (such as different font + larger text) and be able to apply them on top of a single colour change.
  • Given we have no extant examples of accessibility themes, an example of what one could look like is, say, changing the fonts in a skin like Vector or Timeless - the fonts are declared in a variable; we simple override that variable and they should get changed everywhere the fonts are redeclared (not just the body, but for things like overriding header fonts and whatnot back to their base values; this way we only need to change it one place and don't need to worry about manually overriding them again everywhere the skin originally did this).
  • This will also be the foundation for allowing wiki-side stable customisation. Essentially, at some point, we will want to enable wiki admins to change the base colours of their wiki by simply setting those colours through an interface. Wikia has something like this...

Caching was brought up as a potential issue here. Given that user preferences and customisation already totally breaks the cache for logged-in users, and a default theme for a site is set in the same way as a skin and displayed consistently for everyone else, would this actually be a problem in practice?

@Krinkle: Could you please look at Extension:Theme as it is currently? What we want to do in terms of registration is pretty much what it does now, but such that 'themes' are a recognised concept within ResourceLoader (core MediaWiki) itself so that we can attach theme-specific styles to various different modules, as well, in a clean manner.

Was your understanding such that there might be some way to do this with hooks that:

  • Would have use for more than just this extension?
  • Wouldn't potentially result in conflicts if more than one extension tried to implement them for different or similar purposes?
  • Wouldn't create a significantly larger maintenance burden than simply putting the theme functionality directly into core?
Isarra added a comment.EditedJul 25 2019, 2:01 PM

@Krinkle You also mentioned something about this potentially increasing the maintenance burden for the WMF - could you elaborate? Who in the WMF maintains MediaWiki skinning? One of our main reasons for proposing this is to decrease our overall maintenance burden in this area as the maintainers of this part of MediaWiki.

@Krinkle You also mentioned something about this potentially increasing the maintenance burden for the WMF - could you elaborate? Who in the WMF maintains MediaWiki skinning? One of our main reasons for proposing this is to decrease our overall maintenance burden in this area as the maintainers of this part of MediaWiki.

The Web team own the Interface and Skinning parts of MediaWiki, and have done for years. Sorry that this hasn't been made clear.

The Web team own the Interface and Skinning parts of MediaWiki, and have done for years. Sorry that this hasn't been made clear.

It was; we are aware of them and have worked with them before on some of the aspects they actively develop. I was asking about maintainers.

daniel added a subscriber: daniel.EditedJul 26 2019, 11:21 AM

Caching was brought up as a potential issue here. Given that user preferences and customisation already totally breaks the cache for logged-in users, and a default theme for a site is set in the same way as a skin and displayed consistently for everyone else, would this actually be a problem in practice?

@Krinkle can comment on this in more detail (and correct me if I got this wrong), especially for the ResourceLoader aspect, but I want to quickly clarify that the caching aspect is about caching resource loader modules (or bundles of modules). This is not at all broken for logged in users, and themes would add to the fragmentation of this cache. The cache that is bypassed for logged in users is the transparent caching of the fully rendered HTML page. Caching for skin assets (ResourceLoader or static) still applies. The ParserCache is also still used, though to some degree fragmented by user preferences (this is not related to skins, but it's also a cache for which fragmentation on user preferences is an issue).

This RFC was discussed on IRC on July 24, see the minutes and the full log.

The main outcomes (in my personal understanding) were:

  • Part 2 and 3 are closely related to T112747: Devise a generic way for theme-agnostic stylesheets to adapt to the current theme. The requirements from use cases that drive this RFC should be considered for the solution of that task.
  • Part 1, merging the Theme extension into core, is controversial. For one thing, it amounts to a feature request for core, which needs buy in from the relevant product owners and stakeholders. From the technical side, it was suggested that the Theme extension could act as the "glue" for other extensions and skins that want to register themes, and that it should perhaps be bundled with core, but not merged in. More detailed discussions is needed of the cost and benefit of (and possible alternatives to) merging the extension into core.

The RFC will be marked as "under discussion" for now.

The main outcomes (in my personal understanding) were:

  • Part 2 and 3 are closely related to T112747: Devise a generic way for theme-agnostic stylesheets to adapt to the current theme. The requirements from use cases that drive this RFC should be considered for the solution of that task.
  • Part 1, merging the Theme extension into core, is controversial. For one thing, it amounts to a feature request for core, which needs buy in from the relevant product owners and stakeholders. From the technical side, it was suggested that the Theme extension could act as the "glue" for other extensions and skins that want to register themes, and that it should perhaps be bundled with core, but not merged in. More detailed discussions is needed of the cost and benefit of (and possible alternatives to) merging the extension into core.

While your understanding appears wholly consistent with what happened in the meeting, I should probably clarify a bit, as I'm not sure a lot of what was discussed in the meeting really reflects the reality of the extension/core itself.

  1. T112747 is... tangentially related, yes, but describes a somewhat different and considerably larger problem. That task concerns OOUI themes, and the associated pain point that the variables used in OOUI themes were not consistent with those used by core and various skins/extensions (and last I checked even different OOUI themes didn't necessarily use all of the same variables as each other). Essentially, that task is about consolidating the variable usage and definition across different components entirely, that the same variables be defined, available, and used between different parts of MediaWiki, extensions, and associated libraries. While we all agree that consolidation of variables throughout MediaWiki would be good, that would be a matter of consolidating any skin variables with core, OOUI, extensions, etc, regardless of whether or not we have themes in the skins themselves (as skin themes would generally share variables already). Thus that is out of scope for this RfC.
    1. Part 3 concerns adding a specific ResourceLoaderFileModule (or such) to allow easier reuse and redefinition of already defined and consistently applied variables within a single skin (as opposed to just including the module directly in the skin or doing some weird includes gymnastics, which are both already possible and do technically work).
    2. Part 2 is about allowing themes to be interpreted by ResourceLoader in a way that would allow different skin variables to be reused in ResourceLoaderSkinStyles within the current skin. Currently, we simply include the variables file in these and it works for a single set of skin variables; the problem is if we have multiple themes we have no way of knowing, from here, which variables file to include. This needs to be fixed in a way such that ResourceLoader can provide/maintain this information across all of these files, with the specific proposed method in Part 3 being that we define that as another variable via ResourceLoader itself.
  2. Why is Part 1 controversial? Yes, it definitely appears to be, but if anyone can shed some light on what the actual issues are, that would help a lot. As is, I can really only conclude that nobody actually read the RfC or looked at the code itself, because as far as I can tell the main reason to merge it is in fact that Part 2 simply isn't feasible in any other way.
    1. Either we merge this stuff directly, or we add a bunch of hooks that will be considerably harder to maintain and result in potential and likely pointless conflicts between extensions (someone please correct me if I'm wrong on thus, preferably with a specific proposed implementation, but having actually worked with this code I'm just not seeing any alternatives myself).
    2. The described cache fragmentation seems like it would be pretty similar to back when we had like eight different skins regardless: for most skins, especially on projects like Wikimedia, we're not going to be looking at more than 2-3 themes per skin out of the box regardless, and a lot of them still aren't going to have any. A dark and a light mode for Vector and perhaps Minerva and monobook; a dark, a light, and a colourful mode for Timeless, and... that's basically it. We want to be making it feasible for people to add more to their own projects, actually properly customising them, as well as moving toward support of more specialised (and likely skin-agnostic) theme-like objects for various accessibility settings (this is more likely when we'll run into T112747 as a blocker), but we're not proposing a cambrian explosion, here. All in all, the overhead should be fairly negligible.

Whatever the case, I also cannot really recommend doing anything encouraging wider adoption of any stage of this until Part 2 is resolved in some way, as either it will break backwards compatibility, or we wind up with two ways to do the same thing in the extension, one of which doesn't really work properly, and that's just going to confuse people.

Daylen awarded a token.Sep 2 2019, 3:26 AM
Daylen added a subscriber: Daylen.