Requests for comment/Themes in core

Background
definition of skins vs themes

Skins: mediawiki extensions implementing the overall page, including general layout and placement of content and tools
 * MonoBook, Vector, Minerva, Timeless

Themes: Variants of skins in terms of colours, fonts, simple layout changes
 * Night mode versions of skins, simplified layouts, different colours on the same general page structure (green, blue, red versions of BlueSky)
 * Implemented in ext:theme by allowing skins to specify stylesheets that load over, or instead, of the default stylesheets for the skin

expressed demand for theme functionality:
 * wishlist items: (Community Wishlist Survey 2019/Reading/Night mode, Community Wishlist Survey 2017/Reading/Night-mode for read articles?)
 * gadgets and user styles onwiki implementing various (Skin:Vector-DarkCSS Skin:Grey Vector etc, Skin:Timeless-DarkCSS, that green-black enwp gadget)
 * third-party projects customising common skins like vector/monobook (darthipedia, gw2wiki, and other thematic and game wikis in particular)
 * forks of vector etc where all they're really changing is the css
 * external tools such as wikiwand, winter, whatever

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


 * 1) fragmentation
 * 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) should be migrating from css overrides to setting different variables as the standard; need a consistent approach in the first place to head toward this

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.