Requests for comment/Themes in core

Background
The terms 'skin' and 'theme' are often used interchangeably, as different products will tend toward one or the other for the same general purpose - a specific styling of the user interface/layout for the product. While these both hold true for MediaWiki as well, 'skins' and 'themes' are each specific things within this context:

Skins: MediaWiki extensions implementing the overall page, including general layout and placement of content and tools, in order to construct and output the final html, css, and js that visitors receive
 * Examples: MonoBook, Vector, Minerva, Timeless

Themes: Variants of a skin in terms of colours, fonts, simple layout changes; specific to a given skin
 * Examples: Night mode versions of skins, simplified layouts, different colours on the same general page structure (such as the original green, blue, red, and white versions of BlueSky)
 * Implemented by Extension:Theme to allow skins to specify alternate stylesheets that load over, or instead, of the default stylesheets for the skin

Skins a built-in specified part of MediaWiki core, and so are relatively consistent and straight forward, but themes are currently only implemented in a third-party extension and (inconsistently) in a few specific skins. Because of this, we see repeated requests for use of the functionality both on larger projects like Wikimedia and among smaller third-party projects, but for the most part little comes of it. What implementations we have seen are varied and scattered.

Expressed or demonstrated demand for theme functionality:
 * Wishlist items: Community Wishlist Survey 2019/Reading/Night mode, Community Wishlist Survey 2017/Reading/Night-mode for read articles?, others?
 * Gadgets and user styles onwiki implementing various style changes to specific skins: Skin:Vector-DarkCSS Skin:Grey Vector etc, Skin:Timeless-DarkCSS, that green-black enwp gadget
 * Third-party projects customising common skins like Vector/MonoBook: Zelda wiki (using Theme extension), Darthipedia (was CSS over the MonoBook skin in MonoBook.css + some other stylesheets), GW2wiki (css changes to Vector and MonoBook via MonoBook.css, Vector.css, Common.css), and other thematic and game wikis in particular)
 * Forks of Vector/MonoBook where all they're really changing is the css (one of the most common ways to create a new skin)
 * External tools such as WikiWand, Winter, others

Problem
The desire for this functionality and the badness of the skinning system in general result in several issues:


 * 1) Fragmentation of implementation methods
 * 2) * Skin developers may not want to depend on a separate extension, and roll their own solutions (sometimes based on the extension, sometimes not)
 * 3) * no standard approach, so not standard way to fix/update them as core changes - maintenance nightmare
 * 4) * Even if the solution built-into the skin is initially based on and compatible with the Theme extension, still a maintenance nightmare as they fall out of date
 * 5) * caching issues in different implementations? ashley please comment, does ext:theme have problems with this?
 * 6) difficult to implement due to having to install extra things for support and/or start from scratch
 * 7) * developer solutions tend toward front-end js- and css-only overrides instead of working with some of the newer, cleaner technologies (such as LESS variables)
 * 8) override approaches are inconsistent; need a consistent approach defined in the first place to head toward cleaner solutions (defining colours/variables instead of overriding them to determine skin behaviour)

We don't even know about most of the variants floating around, customised wikis that do a change and then we never hear back about it.
 * stuff like ZeldaWiki.org's default color scheme (aka the "dark" theme for both MonoBook and Vector) -- born out of a certain necessity, made for a certain site but not necessarily targeting the wider MW platform, "just" the users of that one site. For ones like this, such a significant desk and development undertaking that it's precisely the kind of thing we want to shed light on and perhaps even get those developers to participate in the wider community (="new developers" buzzword and all that jazz)
 * Going forward, this should not require an all-out restyle in Skin.css, either. Needs to be easier for the users to do in the first place.

Proposal
Merge ext:theme into core, migrate toward simpler skin handling from there once we have consistent basic backend/core support

https://gerrit.wikimedia.org/r/c/mediawiki/core/+/465451/ per T122924

Concerns that this could cause skin options to explode; there's already infinite things wikis can do with their own styles/gadgets/whatever, so this, if anything, should help clean that up by providing more consistent predictable options to test against, and putting all the options more in the same place...

Precedent:
 * Basically like allowing mw to have extensions and skins in the first place, where the benefit of those is a simpler, more consistent implementation of what is/was already out there; likewise these are also already out there, so a single standard in core keeps them consistent and simplifies the lot. (the Pandora's box argument is moot for the box's already been opened up a long time ago; we're literally just cleaning up the mess caused by the opening.)
 * MediaWiki:Skin.css, $wgAllowUserCss (and $wgAllowUserJs) are things and have been things for a long time and as long as they've been things users have created custom CSS color schemes and stuff and shared 'em and now we want them to become somewhat standardized and maintained...
 * Extension:Gadgets can be used to implement this wiki-side, but likewise has issues with code review/maintenance across projects. These are more specific (specific to a skin, in fact), so we're proposing to use git/gerrit for skins' themes in the skin repositories, which is both neater in terms of UX (skin-related stuff showing up with specific skin as opposed to in massive list of usually skin-agnostic gadgets) and review/maintenance/development.