This is some TemplateStyles todo.

Description of work

edit

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:

  1. 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).
  2. 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.
    1. This hurts most on mobile, which is approximately 2/3 of all pageviews these days.
  3. 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.
    1. 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.
    2. 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):

  1. Migrating the templates and modules (most-)associated with each of the classes in Common.css to use, or allow the use, of TemplateStyles.
    1. (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.)
  2. 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:
  3. 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

edit

Mainspace

edit

Some specific categories

edit

What to do?

edit

Modules

edit

50 (20ish true positives)

False positives, but need a module API for Module:Infobox anyway...

Have a module API, just wish it were cleaner (.infobox seems to work?)

Templates

edit

infobox not-table-element

border: 1px solid #a2a9b1; background-color: #f8f9fa; margin: 0.5em 0 0.5em 1em; padding: 0.2em; float: right; clear: right; font-size: 88%; line-height: 1.5em; width: 22em;

infobox table

border: 1px solid #a2a9b1; border-spacing: 3px; background-color: #f8f9fa; margin: 0.5em 0 0.5em 1em; padding: 0.2em; float: right; clear: right; font-size: 88%; line-height: 1.5em; width: 22em;

infobox th

vertical-align: top; text-align: left;

infobox td

vertical-align: top; text-align: left;

infobox caption

font-size: 125%; font-weight: bold; text-align: center; padding: 0.2em;

Infoboxes

edit

Medals

edit

Years sidebars

edit

Uncategorized

edit

Other subject spaces

edit

talk spaces

edit

Plainrowheaders

edit

There's probably not a lot of automation we could do, so at best something like:

  1. Define {{Plain row headers}} with content <templatestyles src="Plain row headers/styles.css"/>
  2. Define Template:Plain row headers/styles.css with content:
    .wikitable.plainrowheaders th[scope=row] {
    	font-weight: normal;
    	/* @noflip */
    	text-align: left;
    }
    
  3. Warn external community at phab:T176272 that we're about to do something that might break later
  4. Rename the class in the TemplateStyles version so that it is trivial to see what still needs to be fixed?
    1. Class names also want the dashes in general I think
  5. Request a bot to mass-remove where there is no scope="row" or equivalent on the page in the same bot run.
  6. Request a bot for mass addition, ns0 to start.
    1. Do a mass addition of {{plain row headers}} where the class is present, above each table using the class.
    2. Would do it multiple times per page. This is fine, styles are de-duplicated.
    3. Could be done in the removal step
    4. Could also potentially do the update from collapsible to mw-collapsible with this work, very small intersection overall
    5. Have a discussion at TemplateStyles or VPT
    6. Get BRFA approved
    7. Bot remove Stuff
  7. Work out any remaining uses in ns0 that don't fit some pattern
  8. Remove from Common.css

Nounderlines

edit

nounderlines, 2k

class=IPA. 8k (mostly in talk namespace)

Nowrap

edit

Another 'ew how do we find these'

edit
  • 1500 uses. Much more manageable chunk to bite.
  • Looks like we need a nowraplinks block of some sort.

Math fonts

edit

texthtml basic filter for no-talk-space 2.4k

user signatures:

SQL for user signatures
USE enwiki_p;
SELECT user_name, up_value
FROM user_properties
JOIN `user` ON user_id = up_user
WHERE
	up_property = "nickname" AND
	up_value LIKE "%texhtml%" AND
	up_user IN (SELECT up_user
				FROM user_properties
				WHERE up_property = "fancysig" AND up_value = 1) 
ORDER BY up_user ASC

'digits' Wide 5k

toccolours

edit

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

Another honorary addition due to its removal from Vector 2022 styles, see phab:T314254

2.2k total

mw-ui

edit

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.

Uses, less user space and talk space: [1]

Flagicon

edit

Modules:

Templates

Turn mobile.css/js totally off

edit

Via User talk:Jon (WMF)#MW:Common.css on mobile we can have no more mobile.css/js!

'wgMFCustomSiteModules' => [
	'default' => true,
	'enwiki' => false,
],

Dark mode: metadata

edit
  • 190 uses need to be adjusted to be dark mode friendly
    • Ok, this class doing some useful work in substed content and IDK what to do about that fact. Just add color and remove the class?
    • Also, I don't get this class's existence, I'm pretty sure it was originally intended for article "metadata" but it crept in to other uses.

Dark mode: side box

edit
  • Should be easy, but has to be done after metadata I think since I think our side boxes are output with the metadata class

Dark mode: navbox

edit
  • Shrug emoji face thing. Probably about as difficult as dark mode infoboxes

Dark mode: quote box

edit
  • Should be easy

Dark mode: infoboxes

edit
  • May or may not make this part of the overall inclusion of infoboxes

Hacks.less: infoboxes

edit
  • Need to sort out the mobile styles for infoboxes

Hacks.less: hatnote

edit

Hacks.less: ambox

edit

Remnants of things

edit

Mbox

Merge MediaWiki:Filepage.css upstream, to our own templates, or delete

Keep in Minerva.css:

/* Prevent unnecessary margin at the bottom of centralnotices */
.cnotice {
	margin-bottom: 0 !important;
}

Done

edit

User block

edit

On its way out per discussion.

Coordinates

edit

Need to fix up remaining .css pages

Listenlist

edit

Basically only Template:Multi-listen start.

Columns

edit
  • class=columns for general uses
    • 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]

Reflist

edit
  • Remove columns, reflist from Common.css.


Monitoring:

Another related monitor

Hide checkboxes

edit
/* Make it possible to hide checkboxes in <inputbox> */
.inputbox-hidecheckboxes form .inputbox-element,
.inputbox-hidecheckboxes .mw-ui-checkbox {
	display: none !important;
}

Moved to Template:Hide checkboxes.

Visualhide

edit

On its way out per discussion.

Hatnote

edit


edit

WP:NavFrame

edit

NavFrame

mw-collapsible
mw-collapsible mw-collapsed
padding: 4px; border: 1px solid #a2a9b1; text-align: center; font-size: 95%;
padding: 4px; border: 1px solid #a2a9b1; font-size: 95%;
font-size: 95%;

NavHead

line-height: 1.6em; font-weight: bold; background-color: #ccf;
line-height: 1.6em; font-weight: bold; text-align: center; background-color: #ccf;

Wrapper for centered text

<div style="margin: 0 4em">
</div>

NavContent

mw-collapsible-content
font-size: 100%;

Bordered images galleries

edit

bordered-images

Misc subcomponents completed

edit

Bordered

edit

Not main not talk 153 insource:"infobox bordered", Not main not talk insource:bordered insource:class insource:infobox -insource:"infobox bordered" 30 Ignoring insource:class...

Geography

edit

And now, we wait.

Found some more: search on bodyclass instead of class

And mainspace (100)

Sisterproject

edit

wikitable/toc hlist

edit
/* ...unless they also use the hlist class */
.toc.hlist ul,
#toc.hlist ul,
.wikitable.hlist td ul,
.wikitable.hlist td ol,
.wikitable.hlist td dl {
	text-align: inherit;
}

Just need the list at WT:HWY#Cleaning up some 'manual' routes/junctions fixed up and then can remove the wikitable.hlist variants.

Stuff that is concerning because both cargo-cult and because an issue for here.

Stuff that is concerning because cargo-cult, but not an issue for here.

edit

Citation

edit

messagebox

edit

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.

.messagebox

style="border: 1px solid #a2a9b1; background-color: #f8f9fa; width: 80%; margin: 0 auto 1em; padding: 0.2em;"

standard-talk

edit

46.9k uses

.messagebox.standard-talk:

style="border: 1px solid #c0c090; background-color: #f8eaba; width: 80%; margin: 4px auto; padding: .2em;"

cleanup

edit
  • 49 non-user/talk
  • 3.6k user/talk not caring about
style="border: 1px solid #9f9fff; background-color: #efefff; width: 80%; margin: 0 auto 1em auto; padding: .2em; text-align: center;"

compact-ambox

edit

Read:

Modify

mbox (initial)

edit

Have to figure out how to deal with the ambox+ambox rule, but other than that, just have to find the insanity and clean it.

250

these need chasing after

700 no user talk

80

140

tmbox/ombox talk other split with small-talk adjustment:

{{talk other|border: 1px solid #c0c090; background-color: #f8eaba;|border: 1px solid #a2a9b1; background-color: #f8f9fa;}} margin: 4px 0 4px 1em; border-collapse: collapse; box-sizing: border-box; clear: right; float: right; width: 238px; font-size: 88%; line-height: 1.25em;

Final cut

edit

WikiProject banners

edit

Plainlist

edit

Wherein Izno ponders how best to deal with infoboxes. Expanding the styles direct:

The done ones.

Hlist

edit

Hlist templates/modules

edit

Primaries

Secondaries

Others:

hlist-separated

edit

Assess hlist-separated (definition), pretty sure it harms more than helps

Upstream definitions of hlist are:

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.

Namespaces

edit

Fake infobox-sidebars removed

edit

multicol

edit
  • 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]