The below to do page is the list of styles in MediaWiki:Common.css and friends which are to be converted to TemplateStyles. These are being converted to TemplateStyles for multiple reasons:
To allow ordinary users and administrators to change "sitewide" styles. Editing Common.css is restricted to interface administrators (i.e. not many people) since late 2018, whereas the majority of the styles in the CSS sheet are fairly benign. Accordingly, moving styles to TemplateStyles and out of Common.css allows a much larger set of people to be able to make changes to widely-used styles (all administrators, and even the vast majority of templates are template protected rather than full-protected).
To decrease the page load on all pages. Every style rule in Common.css, whether used or unused on a specific page, is loaded on all pages. For example, if you have made a stub and it has no navboxes, it still gets the styles for navboxes, infoboxes, horizontal lists, and so on (until the list of sets of styles is empty). This means that pages load slightly slower for everyone on all pages.
This hurts most on mobile, which is approximately 2/3 of all pageviews these days.
To return power to style mobile to local editors. Right now, many of our styles in Common.css were not carried over into mobile for a couple reasons.
The primary reason is that MediaWiki:Mobile.css loads after, rather than before, the rest of a specific page. Accordingly, adding styles to it can cause FOUCs ("jumpy pages while loading"), which are generally bad for both user experience, and these days, search engine optimization (you don't really need to care about the second one if you don't want to). We no longer use Mobile.css (instead we use Minerva.css), so this isn't relevant. And will soon be using only Common.css unless skin-specific styles are necessary.
The second reason is that the WMF has more or less picked up the slack that has created in how our pages look on mobile.
Now, whether you like the mobile styles or not, it is probably the case that the editors onwiki should decide how the wiki should appear on mobile.
Migrating requires three broad steps (which do not necessarily happen in this order or sequentially):
Migrating the templates and modules (most-)associated with each of the classes in Common.css to use, or allow the use, of TemplateStyles.
(Or for some templates/modules, removing the class entirely from sitewide CSS and using inline styles instead of TemplateStyles. This is most common with substed templates, which TemplateStyles are not great with.)
Migrating the large number of non-templates and non-modules which use the classes in Common.css to use the template or module instead of the class. (Sometimes this necessitates removing the use entirely rather than migration.) This migration is because in #3, we:
Remove the styles from Common.css.
Edits of the type as in #1 mostly happen in the background as editors of templates are basically the only ones who need to be interested in those.
However, edits of the type in #2 happen outside the template and module spaces. A consequence of #3 is that pages with the manual classes invoked will lose their styling if an appropriate template is not in place to provide that styling.
Editors performing this kind of edit are doing their best to replace uses of a class with the appropriate template. They won't always get it right, so if you see them get it wrong or in a way you don't like, either endeavor to correct the edit if you know how, or ask the editor about making a better change, in preference to reverting if at all possible.
Infobox
Find and replace with a standard infobox or remove the infobox class, where applicable
Honorary addition due to its removal from Vector 2022 styles, see phab:T314254.
In general, the uses should be transitioned to another reasonable class, such as wikitable in mainspace or changed to a template to at least isolate the class name for now.
23.8k all
Do what we can to ease transition to as-yet unknown replacement for wiki content using mw-ui. See phab:T346468.
Probably the use of {{clickable button 2}} needs to stop taking "class" and start taking some sort of "kind" or "type" i.e. kind=progressive or kind=destructive, and then deprecate the use of a direct class.
Decide what to do with MediaWiki:Print.css, if anything, as that will come with. It's pretty small, and now that mw-collapsible loads on mobile it should be finishable?
Not sure if I want to split this to a generic templatestyles page or reimplement this in two places. The major implementers seem to be {{div col}} and {{reflist}} and that's it (and some copies of those). Not so many general uses that we need to combine CSS, I don't think.
Split
Just have to implement in {{reflist}} now, which coincidentally may be ripe for clearing out also.
And now also have to beat people over the head convince people that this is the preferable implementation in Module:Goalscorers. And in fact that they shouldn't be using absolute columns. (We really need that template deleted.)
Have to survey module/template space also, specifically. Not sure of the best way to do that.
Surveyed by searching. insource:class insource:columns insource:/[\'\" ]columns[\'\" ]/ -intitle:testcases -intitle:sandbox -intitle:doc -intitle:"did you know"[2]
/* Make it possible to hide checkboxes in <inputbox> */.inputbox-hidecheckboxesform.inputbox-element,.inputbox-hidecheckboxes.mw-ui-checkbox{display:none!important;}
/* ...unless they also use the hlist class */.toc.hlistul,#toc.hlistul,.wikitable.hlisttdul,.wikitable.hlisttdol,.wikitable.hlisttddl{text-align:inherit;}
Most of the uses outside userspace of messagebox and/or standard-talk are probably due to substed XFD results and a handful of other templates random substed onto talk pages (e.g. {{talk header}}). A typical example. We should probably try to unsubst these as best we can.
Module:Infobox: I think the quantity of infoboxes below and how plainlist is being used in each is worth supporting the same "find list class" in the module as expected for the sidebar and navbox modules. [5]
Based on review of the above, we can remove hlist-separated once hlist/styles.css is deployed in the above templates, and never look back. TemplateStyles should provide the correct view always, due to higher specificity (the addition of .mw-parser-output), by proximity (will be found 'later' in the page), or predominantly, both.
Correct these uses either to use an appropriate column template or remove because it's not valid to use this class (this class is specifically multicol and not any of the other names floating around that look like it): [8]
