MediaWiki talk:Gadget-Site.css/todo

From Wikisource
Jump to navigation Jump to search


MediaWiki:Gadget-Site.css[edit]

This is likely to needs to stick around long term, since I've no illusion we'll manage to upstream all our needs this side of the heat death of the universe (a geek can dream, though!). Should be slimmed down considerably though.

All header-related classes[edit]

That's everything above the Score classes. These are in a slow process of moving to TemplateStyles, as we migrate the jungle of discontiguous templates to a single Scribunto module at {{header}}. This also hits every mainspace page and every author and portal page, so hurrying slowly is definitely the name of the game.

.mw-ext-score classes[edit]

Probably need to live on, here or in enws-tweaks.css (depending on whether we keep them separate). Should be in TemplateStyles, but since mw:Extension:Score is an extension tag… Maybe upstream a request for some TemplateStyles-like mechanism? Could also be worth assessing if both these are still needed. max-width probably is, but the display:table one might not be.

I cannot replicate the behavior that causes the reported issue for the second block in Vector. And I honestly can't see why the display: table is there either (though display: table would be likely to cause the "score is falling out of its container" issue, i.e. self-inflicted bug). Izno (talk) 18:54, 25 November 2022 (UTC)[reply]
Weird. The workaround for T218191 was added first, and then a month later the display: table; margin: auto; was added in order to center scores by default. So it's not a self-inflicted problem at least (but then multiple projects reported problems here so that was unlikely). I think Score just outputs an image of a given page size at a given DPI, so the width in px is given. The image is wrapped in a div that by default is an inline-block, so it'll size to the image's intrinsic width. In other words, I think it'll inherently overspill any width smaller than its intrinsic width. Being inline also seems undesirable for all but the most trivial uses (though I would have gone for a plain block instead of table).
As mentioned, I suspect we'll just have to live with this one barring upstream changes, but I'd like to have Inductiveload's input on this one since they were the one actually looking at the problem. Xover (talk) 18:39, 26 November 2022 (UTC)[reply]
I would really like you to get rid of the automatic centering of scores—it's a nuisance throughout the DMM as there's no sensible way to put scores inline. I'm happy to centre those that need to be. With the exception of a hymn-book, most of the scores I've done shouldn't be centered, rather they should be inline or left-justified. When I need scores to be left justified I've been putting them in a table, and now I discover that I'm basically table nesting as a workaround. Beeswaxcandle (talk) 23:11, 27 November 2022 (UTC)[reply]
I would tend to agree. Hmm. And it was only added in feb. last year, before which the expectation would have been the unaugumented version. Maybe we can just remove it and accept that some scores added in the last ~20 months may have been added under different assumptions? The expectations for everything added in the decade+ before that would have been the unaugmented version.
But I'm starting to wonder whether it would be worthwhile to make a Scribunto module to wrap Score, so that we can make it easy to add a block wrapper with auto margins (i.e. centering it). Wrapping extension tags is a bit yucky, but doable; and it would let us put stuff into TemplateStyles instead of site-wide CSS. It would probably have to be designed a bit like {{ppoem}} since calling an extension tag inside Lua requires having the full contents (i.e. we can't just manipulate the start tag and rely on the user to add the closing tag), but that might also make it easier to use scores across multiple pages (if that's an issue today). Xover (talk) 12:22, 28 November 2022 (UTC)[reply]
Multiple page scores continue to be a problem, especially where the auto-generated sound file is wanted. My work around has mostly been to put it all on one of the pages and leave transcriber notes explaining what I've done. It's not ideal for the WS workflow, but the headaches of essentially splitting a single Lilypond file across several pages and then putting it back together again for transclusion is really not worth the candle. Mutopia (a PG-style score repository) deal with long Lilypond scores by simply ignoring the print page breaks and producing the appropriate scores from a single file. Beeswaxcandle (talk) 17:21, 28 November 2022 (UTC)[reply]
@Xover not sure what input I can provide - maybe block is better than table, but otherwise that's the idea: centre in the page and keep them on the page. Since they're otherwise fixed-width in pixels, they easily end up off the page on any kind of mobile screen, which is usually only about 350-ish effective pixels wide (see Help:Preparing_for_export#Formatting_for_small_screens). And as @Izno says, this isn't from a template.
If the centering isn't actually wanted, then get rid, I suppose. @Beeswaxcandle, but would {{Score aligned block}} work better than left-aligning everything to the page margin by default? Inductiveload—talk/contribs 22:04, 2 December 2022 (UTC)[reply]

.pagetext class[edit]

Justifies the text in PRP's output in Page: namespace pages. We should probably retarget this selector to the namespace, but otherwise it probably needs to live on. Or at least I can't see any clear alternative since we can't upstream it (not all users of PRP will want this style).

Yup, I agree that I think this is a keep. .prp-index-pagelist-page adjustment is also pertinent here. Izno (talk) 22:53, 27 November 2022 (UTC)[reply]
Moved to a separate gadget that only loads in Page:-namespace (now that we have the ability to do that). Xover (talk) 15:55, 27 April 2024 (UTC)[reply]

Narrow screen adjustments[edit]

This should probably be a facility of the skin, but… Not sure where we're using this that doesn't have its own TemplateStyles (e.g. Main Page), but we probably have to retain this for the foreseeable future.

There is already .nomobile available, which MobileFrontend and responsive skins may/may not have CSS attached to it (I wish there were two classes here, one for MF to rip out .ext-mf-remove and one for skins to target .nomobile). My personal opinion is that you should never hide content from mobile, only attempt to move it so that it appears reasonable, but that's a decision you can make.
Regardless I see no reason to keep this in a global sheet. It's used in only these two places:
Main Page can take the style directly and Desktop only can take it via TemplateStyles, and then remove from the two MediaWiki space pages. Izno (talk) 22:59, 27 November 2022 (UTC)[reply]

hr max-width[edit]

Can't we do this in {{rule}} TemplateStyles? Do we need to migrate raw hr tags to {{rule}} first?

As before, in general, HTML elements without any sort of attempt to style a specific class should be left in a central location (whether here or one of the skin files), because HTML elements otherwise need to be monitored onwiki. Given that this is much more commonly used, it should probably either a) remain in central CSS or b) migrate to the skin level. I don't personally understand the desire or need for this CSS however, so that needs to be understood before either (I think it would be more fruitful to identify hrs with a width > 100% instead and fix those rather than using global CSS). Added here by Inductiveload. Izno (talk) 18:37, 25 November 2022 (UTC)[reply]

Uses: 30k, and that's just the wikitext version. I don't think moving is practical.

@Izno: As with similar for img and other replaced elements, the issue it's addressing is that "100%" sometimes ends up being more than 100vw, meaning you get horizontal scrollbars even on insane screens, etc.
This is one of the cases where we probably want to long-term move raw wikimarkup (styling owned by MW/skin) to a template (where we can own styling), and maintain the max-width there. --Xover (talk) 10:02, 26 November 2022 (UTC)[reply]
Good luck. I don't think that's worth it. Adding max-width upstream seems reasonable by comparison. :) Izno (talk) 01:09, 27 November 2022 (UTC)[reply]
Indeed, the {{rule}} template is usually what you want anyway, as it's likely you actually do, usually, want a black rule "as printed", and not Mediawiki-skin-themed. Inductiveload—talk/contribs 22:18, 2 December 2022 (UTC)[reply]

@media print text-align[edit]

@Inductiveload: These are yours I believe? Any alternatives to keeping them in site-wide CSS? Are they still needed? At first blush I would guess we need to keep these here, but in the interest of re-evaluating everything critically…

I don't think there's much we can do about that, since otherwise anything centred or right-aligned will be overidden by the default CSS: phab:F35829065. The default CSS is something like this:
@media print
p {
  font-size: 12pt;
  line-height: 16pt;
  text-align: justify;
}
Which is certainly a blunt implement, but I guess the logic was "works for Wikipedia"! Inductiveload—talk/contribs 22:15, 2 December 2022 (UTC)[reply]

OOUI hacks[edit]

Also by Inductiveload. OOUI is dead and T280543 will never be fixed since Codex lands Real Soon Now™ and Will Solve Every Problem With No Coding And Lots Of Transpiling Server-Side Rendered Component Patterns For The Win™. Are these worth keeping around until whatever tickles the bug is migrated to the new Codex-based hotness (RSN!)?

I think that's been quietly fixed actually - the upstream CSS is now setting margin-left: -6em rather than margin-left: -2.35714286em; Inductiveload—talk/contribs 22:24, 2 December 2022 (UTC)[reply]

MediaWiki:Gadget-SiteHeader.css[edit]

Without delving deeper, I'm guessing this can move entirely to {{header}} and its TemplateStyles once we finish migrating that to Lua.

Done but could have more work if someone wanted[edit]

.prose and .indented-page classes[edit]

Uses of these should move to dynamic layouts, but some are vehemently opposed to dynamic layouts and others are just vehemently attached to the way they have done things. At the very least we need to check that the .prose and .indented-page styling matches fairly closely with one of the dynamic layouts. Also, if these are among the old classes that MediaWiki:Gadget-PageNumbers.js actually removes when it runs then maybe we can just drop them unceremoniously (maybe botting away the old uses of the classes, maybe leaving them in place as dead code).

Would generally recommend to remove by bot first. Good luck. Izno (talk) 22:48, 27 November 2022 (UTC)[reply]

There are too many variants to reliably get both the opening and closing tag with a naive (regex) parser, so I'm going to just leave these in place for piecemeal cleanup. But I removed the selectors since they've been non-functional for ages. Xover (talk) 23:47, 3 December 2022 (UTC)[reply]

div.fslhInherit > p[edit]

p-wrapping must be killed with fire! Someone please bribe cscott with a castle in Bavaria or something to assassinate it… *sigh*

This is probably a global workaround for a p-wrapping problem that was common to a small number of templates, and probably at least due to a then-current voodoo belief that line-height: inherit should always be set explicitly. We need to figure out where this is actually used and then either TemplateStyles-ify it or ust drop it if not needed.

Done, please look over. I am not really sold that the importants are necessary and there is a question about the common styles with Template:Font-size90%. Izno (talk) 22:16, 27 November 2022 (UTC)[reply]

Looks good. So I just made both variants use that stylesheet and nuked the site-wide selector (got rid of the !important as well, but core/skins have previously set some pretty specific stuff on paragraphs so I won't be surprised to find we need to add those back in).
A better question is why {{fs90}} (90%) exists at all, given {{fine}} (92%) is our standard sizing template. Xover (talk) 00:16, 4 December 2022 (UTC)[reply]

cite *.printonly[edit]

Is this needed for anything? We don't use raw cite tags, and our use of the CS1/2 citation templates should be minimal (inappropriate in content namespaces, so only on Author: and Portal: pages plus project spaces). All citation templates should do this through some other mechanism, typically TemplateStyles.

You actually do, and they appear to be correct uses of the tag (later cleaning mission). That said, I removed this from en because printonly was unused.

NB Template:Citation is still using wikitext. It looks like you have a functional Module:Citation/CS1 powering your citation templates here, so I don't know why. Izno (talk) 07:55, 27 November 2022 (UTC)[reply]

Because we have no legitimate uses for citation templates here—none that I've run across anyway—so I haven't prioritized spending time on resyncing them from enWP (and with Trappist dropping changes every two weeks we'd be rapidly outdated again anyway). But I nuked this selector in any case. Xover (talk) 00:22, 4 December 2022 (UTC)[reply]
Sure. The assertion I'm making is that you can copy over specifically Template:Citation today from en.wp and you shouldn't have any more issues than having already copied over the various CS1 templates (cite book etc.). Izno (talk) 22:16, 6 December 2022 (UTC)[reply]

Done[edit]

Ruby text[edit]

Is this really needed? Sounds like the responsibility of the skin to set this sanely. Maybe we can find a template whose TemplateStyles it can live in, or set it using dynamic layouts? Not the end of the world if it lives on in Site.css, but we use Ruby annotations on very few pages so it would be nice if not every page load had to pay for it.

In general, HTML elements without any sort of attempt to style a specific class should be left in a central location (whether here or one of the skin files), because HTML elements otherwise need to be monitored onwiki. On this wiki which is basically English-only, for the specific element <rt>, which is used exclusively for marking up ruby annotations for Asian languages, I'd expect the use to be fairly close to nil. Here's a search and indeed the only valid non-template use is Page:和英英和語林集成.pdf/1006. So you could feasibly get away with moving this style to Template:Ruby (used on some 150 pages). The issue with that path is that you then have to monitor for use. (I think English Wikipedia does not style this one in Common.css, and we have a much wider use case for it, but we maybe should, though no-one should be using it without a template to support that use given how generally complex the use is.)
The use in Template:Manuscript Replacement is a misuse and should be corrected. Izno (talk) 18:30, 25 November 2022 (UTC)[reply]

Used in

Calling this one done. I rewrote {{Manuscript Replacement}} to use non-ruby elements (Ruby is at best borderline valid for that use), and then just removed the tweak from Site.css. The default is 50%, so forcing 60% has minimal utility and can be set in either TemplateStyles or Index CSS if needed. {{ruby}} already sets it to 85% now (after I re-synced it from enWP). @Inductiveload: FYI since you added it. --Xover (talk) 09:52, 26 November 2022 (UTC)[reply]
@Xover looks good, thanks! Inductiveload—talk/contribs 22:34, 2 December 2022 (UTC)[reply]

.fileinfo-paramfield class[edit]

Should move to TemplateStyles for {{information}}, but we have technical debt in that it's an old Commons import that we haven't kept updated; and can't now easily update due to Commons' weird bespoke i18n system. Maybe see if enWP's template can be a drop-in replacement, or maybe rewrite our own system from scratch. It needs significant work template-side before we can get rid of it in any case.

You can pull this from en because en's not weird. I'd just recommend double-checking the parameters and the categories and then copy-pasting; the template itself is basically trivial. --Izno (talk) 18:43, 25 November 2022 (UTC)[reply]
It's used by {{book}} too, for which enWP has no equivalent. Xover (talk) 19:14, 25 November 2022 (UTC)[reply]
True. I'm not sure it's relevant though. You just put the styles in one place regardless. In general, you can and should move styles without getting stuck in total rework: focus on removing uses that aren't inside a template and then deploy the TemplateStyles and then work on making the templates beautiful. Izno (talk) 01:36, 26 November 2022 (UTC)[reply]
Meh. I just dumped it in Template:Information/styles.css and called it a day. Removed from Site.css so for this todo it's done. --Xover (talk) 10:15, 26 November 2022 (UTC)[reply]

Used in:

span[data-descr][edit]

I have no idea what these do, but since they're tagged as temporary they are likely removable. Need to check who added them and when (if that someone was Inductiveload then bug them about it; if it was George Orwell III then kill it with fire and deal with the fallout).

Appears neither onwiki nor in source. Removable. Izno (talk) 05:42, 26 November 2022 (UTC)[reply]
Added by GOIII in 2015, as part of an experiment with lightboxes that was abandoned shortly afterwards. I've removed it. --Xover (talk) 23:38, 26 November 2022 (UTC)[reply]

.infobox classes[edit]

The .infobox classes should go away when they are no longer needed. This depends the {{infobox}} family moving to TemplateStyles. Our styles for infoboxes are not up to date / in sync with enWP, but none of the differences appear to need to be preserved.

As I said elsewhere, these can/should be moved to Module:Infobox/styles.css today. Izno (talk) 07:29, 27 November 2022 (UTC)[reply]
Moved. --Xover (talk) 09:53, 27 November 2022 (UTC)[reply]

System messages styled similarly to fmbox[edit]

These have been copied from enWP, but I don't think anyone would miss them if they were gone. The system boxes are the basic responsibility of MediaWiki, so if any styling is critical it should be upstreamed. In other words, these can probably just go away.

No comment. Izno (talk) 07:30, 27 November 2022 (UTC)[reply]
I nuked ’em. This is "pretty" styling for a situation that should occur extremely rarely, and whose sensible styling is an upstream responsibility, but we're paying the price on every single page load.


ul[type="*"][edit]

Any live uses of these should be wrapped in a template (or possibly be removed and replaced with something simpler) and the styles moved to its TemplateStyles.

ul[type="*"] is invalid HTML today, in favor of CSS. (MDN lists it as invalid and the spec does not list type as a valid attribute.) ol[type="none"] is also invalid according to the the spec (types must be one of these 5 items in the table).

  • I believe ol is [1], which looks clear. {{ol}} checks for invalid type attribute. I don't see any other templates that could separate the attribute and value in [2]. So I think this rule can be removed.
  • I believe ul is [3], which is clear. [4] is also empty in the same manner as above. So I think these rules can also be removed.

Izno (talk) 08:54, 27 November 2022 (UTC)[reply]

Nuked. Xover (talk) 10:03, 27 November 2022 (UTC)[reply]


.usei lists[edit]

This needs some investigation. The class is designed for a specific type of work, so we can't use per-work CSS (aka. "Index Styles") for it very easily. As a list usage in already very complexly formatted works, wrapping the uses in a template may not be straightforward. Probably need to find the existing usages and devise strategies for them. In any case, this should very definitely be migrated away from the global Gadget.

Either this can be addressed by paired templates (a la Template:Flatlist) or one backed by Module:List (a la Template:Ordered list). I think the numbers should be doable in pure CSS rather than in a mix of CSS and HTML. Assuming you don't want to fork the upstream for one use, I'd suggest a new template {{usei list}}. --Izno (talk) 06:52, 27 November 2022 (UTC)[reply]

The one use was excessive, so I replaced it with a plain ordered list and removed the styles. Xover (talk) 13:25, 27 November 2022 (UTC)[reply]

.paren classes[edit]

This needs investigation, but it smells like essentially a per-work style. If there are actual uses of this class in the wild they can probably be migrated to per-work CSS fairly easily.

This one is unused. I'd have recommended the same as the #usei_list above. Izno (talk) 08:00, 27 November 2022 (UTC)[reply]

Removed. Xover (talk) 13:26, 27 November 2022 (UTC)[reply]

.references classes[edit]

Most uses should be inside {{smallrefs}} or another reflist template, and can migrate to its TemplateStyles. But there are almost certainly raw uses of these out there that we will need to figure out a migration path for. 

ol.references {
	font-size: 100%;
}

.references is generated by <references/> which has a default size of 100%. I do not know why that is redeclared here. 

.references-small {
	font-size: 90%;
}

Should probably use {{smallrefs}}: 50 pages 

ol.references > li:target {
	background-color: #ddeeff;
}
sup.reference:target {
	background-color: #ddeeff;
}

This is the default behavior upstream today and can be removed, besides that this is a darker blue than upstream (which makes the link probably in the realm of inaccessible contrast). Izno (talk) 09:10, 27 November 2022 (UTC)[reply]

Removed, while fixing up the above issues along the way. Xover (talk) 20:44, 27 November 2022 (UTC)[reply]

MediaWiki:Gadget-enwp-lists.css[edit]

This Gadget should be emptied and removed.

.hlist classes[edit]

Uses should be replaced with {{hlist}} and its TemplateStyles. Are horizontal definition lists used anywhere? There's no obvious legitimate use case for horizontal definition lists, so maybe any live examples should be migrated away and then the rules simply dropped?

You do appear to have some navboxes and things. I'd suggest keeping the rules for definition lists, which show up in that context on en.wp. Izno (talk) 07:28, 27 November 2022 (UTC)[reply]

Uses

.plainlist classes[edit]

Are probably mostly redundant to {{plainlist}} and its TemplateStyles already. But there may be (possibly numerous) raw uses of the class out there that need some sort of migration before dropping these from the Gadget.

Uses:

I've removed the stray uses of .hlist and .plainlist, proposed some for deletion, but the modules we've imported from enwp I am loath to start forking. With the lack of real support in MW for sharing code, and our chronic lack of technical manpower, it's just not feasible to maintain local patches for anything but the most dire needs. --Xover (talk) 17:24, 27 November 2022 (UTC)[reply]
These are coming to en.wp at some point less the delta in the class name (which you'll have to deal with categorically), I just haven't gotten to it. hlist and plainlist were in the set of things I was working on and then kind of just dropped things because I got burnt out on the project.
Incidentally, the lists on those Pages can use <div style="column-count: 2; column-rule: 1px solid grey"> (column-rule has basically the same properties as border) for more accurate styling. Izno (talk) 22:05, 27 November 2022 (UTC)[reply]
You shouldn't have two classes doing the same thing, flatlist is rocking wst-flatlist and those modules are looking for or outputting hlist, and plainlist has a similar issue. Izno (talk) 05:50, 29 November 2022 (UTC)[reply]
Which can be returned to the other version pretty easily, the "new" names have only wandered to about 15 pages. Izno (talk) 06:03, 29 November 2022 (UTC)[reply]
The wst-*-prefixed classes are intended specifically to not clash with core, skin, or imported code; and to be recognizable as WikiSource Template classes (meaning the associated styles come from that template's TemplateStyles). They're also meant to be targetable from Index CSS (uses TableStyles under the hood, but automatically loads Index:Example.djvu/styles.css on every Page: page and mainspace pages where they are transcluded using PRP's <pages … /> syntax, so that any per-book special formatting can be added. Xover (talk) 23:39, 3 December 2022 (UTC)[reply]
They're still doing the same thing, if that's ok with you. :) Izno (talk) 22:10, 6 December 2022 (UTC)[reply]

Xover, I've made the changes on en.wp over the past two weeks that would support the above templates/modules which I've now pulled and sorted for the crossed out pages (I was apparently pretty close to being done). I inserted some styles into Template:Plainlist/styles.css that were close enough but still you are outputting a few selectors more than you should to support those templates/modules. Template:Hlist/styles.css that I have made today (because it is relevant to those modules) and Template:Flatlist/styles.css are effective duplicates that you will need to resolve, however you want to do that. I am happy to help but my recommendation is to un-fork those class names. Template:Flatlist is accordingly unchanged by my efforts; 'upstream' uses Template:Hlist/styles.css.

MediaWiki:Wikibase-unconnectedpages-summary should simply be deleted as I point out that it is totally unused.

Coincidentally, caught this change that should be made. There are numerous others of this character that will need to be made (not just to support the two list kinds, you obviously already have this issue with message box predominantly), likely to this set of pages. You can either edit the template being used on the page (like Template:Sp-contributions-footer), or you can be lazy and insert the parser-output class in each message as appropriate. On en.wp I did mostly edit the templates as a priority, but that makes it slightly harder to track what's "done" and what's not. (I wish these didn't need to be managed, but it should be a one time cost since future message additions will get a "that doesn't look like it's supposed to" response on the page where the message is used. If somebody notices....) Izno (talk) 01:12, 30 December 2022 (UTC)[reply]

.usei classes[edit]

See also #.usei_lists in MediaWiki:Gadget-enwp-lists.css. List styling up in that section.

usei

h1/2/3/4/5/6/7.usei: This probably wants a Template:Usei heading.

hr.usei: Used only in Template:USStatChapHead, this probably just wants to be merged wholesale into that template and/or its TemplateStyles.

useiList:

useiList
Used in Template:eolist-begin and Template:eolist-item. Move to Template:Eolist-begin/styles.css.
useiListrow
useiListcell1
useiListcell2
useiListcell3
useiListcell4
useiHgindt
All used only for Template:eolist-item. Move to Template:Eolist-begin/styles.css.
useiHdnpad
useiHidden
useiFloatl
Unused.

useiList and co done. Looks like SF00 did the hr style, though didn't rename anything (I would have) and didn't pull any of the styles from the template out. Izno (talk) 05:21, 28 November 2022 (UTC)[reply]

All done now. Xover (talk) 10:17, 29 October 2023 (UTC)[reply]

.HighlightedAnchor class[edit]

Helper class for {{anchor+}} so probably should just move to its TemplateStyles. Unless the sanitizer hates us and prohibits :hover in TemplateStyles.

Nope, :hover is accepted. This should be doable in TemplateStyles. Izno (talk) 05:13, 26 November 2022 (UTC)[reply]

Uses:

This is fixed by use of Template:Anchor/styles.css and can be removed. Izno (talk) 01:58, 30 December 2022 (UTC)[reply]

Removed now. Xover (talk) 10:18, 29 October 2023 (UTC)[reply]

.basicWS classes[edit]

Are these used anywhere? And if they are, are they really needed? The "reset everything stylesheet" was a fad in web design ten years ago, but isn't normally used these days. If there are any legitimate uses they should probably be replaced with specific rules in the templates that use them.

They didn't really die, they were replaced with normalize.css, which just makes everything render the same between browsers (insofar as they have different renderings these days; browsers have been doing a lot of work to make things look The Same). I think I'd probably remove the uses also. Izno (talk) 22:10, 27 November 2022 (UTC)[reply]

Uses:

Uses of this class have been removed. Izno (talk) 03:04, 30 December 2022 (UTC)[reply]

And now the class has been removed too. Xover (talk) 10:24, 29 October 2023 (UTC)[reply]

.nonumtoc classes[edit]

Any raw uses of this should be replaced with a suitable toc template. MediaWiki-generated auto-tocs should not be used in content namespaces in any case, but I fear we have a huge backlog here that is a massive amount of work to deal with. The number of uses of this specific set of classes should be low though, at least outside templates.

Only about 100 uses. It sounds like the TOCs just need removal from main space and then convert the rest. This has an equivalent at w:Template:Nonumtoc which actually just removes the class entirely because you don't need it in TemplateStyles land. NB the arrival of Vector22 will obviously make this also "obsolete", so it might be best to remove all uses totally anyway given how niche it is. Izno (talk) 06:39, 26 November 2022 (UTC)[reply]
Done. The styles for the enWP template removes hierarchical indents for lower-level headings (for some reason), so I had to tweak them locally. :-( Xover (talk) 11:57, 29 October 2023 (UTC)[reply]

Uses:

  • ~60 mainspace pages
  • 5ish author pages
  • 15ish elsewhere.


.clearFix classes[edit]

Are these needed? Don't we have a better alternative provided by MediaWiki / the skins? Anywhere that uses them can probably be replaced by local styles, either TemplateStyles or Gadget-specific styles (whether as a RL dep or in inline JS).

Used only in MediaWiki:Gadget-PageNumbers-core.js. There is no alternative (there was at some point, but let's not get into that). This one oddly defines display on .clearFix as first inline-block then block, so the former can probably be removed. Move the CSS to MediaWiki:Gadget-PageNumbers-core.css and then remove. --Izno (talk) 05:51, 26 November 2022 (UTC)[reply]
Done, and removed. Xover (talk) 13:49, 30 October 2023 (UTC)[reply]


.prettytable classes[edit]

I started in on these, but ran into… something… that blocked it. Should not be used in any content namespaces. MediaWiki table markup is a pain to wrap in a template, but that's probably the migration path. Most uses ought to be replaceable with .wikitable, or so I would assume in any case.

Not equivalent styles, so that's up to you. I don't really think you need to support 'prettytable' but that's just me. As for wrapping tables, just don't. Use a passthrough template like w:Template:Row hover highlight. (Yes, there is a minor risk here that WMF will ban uses like that, but at least one engineer has supported this use.) --Izno (talk) 07:44, 27 November 2022 (UTC)[reply]

800 uses.

Caption
ABC DEF
123 456
Caption
ABC DEF
123 456

I can probably help with this one. I'll need access to AWB.

Why should it not be used in content space, which are you defining as content spaces for the purposes of this item, and what's the appropriate replacement in those areas? Izno (talk) 02:17, 30 December 2022 (UTC)[reply]

"STYLISTIC TABLES" classes[edit]

Probably not very many uses, and a lot of those can probably be replaced by inline {{ts}} in the table. These should in any case all go away one way or another.

.times-serif and span.texhtml[edit]

.times-serif needs investigating but should probably just go away. Any uses have been obsoleted by dynamic layouts.

.texhtml needs further investigation. The class is probably added by the math extension tag, and the styling may be legitimately needed. But math rendering has changed a lot since these were added, so it's possible they are no longer needed and it's possible they are broken (bitrotted) since we have some known math display bugs not reported elsewhere.

These are inherited from en.wp. Neither were used meaningfully. times-serif was removed. Here it's totally unused and you can remove the class name.
There is also digits. It is similarly unused.
texhtml is however a convention by mathematicians marking up math using HTML rather than in a mathematical language e.g. LaTeX. This will be moved out to w:Template:Math which is the primary use but that has some links surrounding it that has stalled removing it from Common.css (see w:MediaWiki talk:Common.css/to do#Math fonts). It's also abused in some signatures that just want to look pretty. In case 1, you don't have this issue. In case 2, if people want their pretty fonts back, they can add those to their signatures. There are some vendor specific here but those are basically unnecessary with the current viewership (and are basically an optimization of display anyway). Izno (talk) 06:28, 26 November 2022 (UTC)[reply]
.digits and .times-serif have been removed. Xover (talk) 14:06, 30 October 2023 (UTC)[reply]

Uses:

MediaWiki:Gadget-enws-tweaks.css[edit]

We may want to keep a slimmed down version of this Gadget rather then migrate the remains into MediaWiki:Gadget-Site.css, just simply to keep different types of styling separate. If Site.css is basic styling for enWS and stuff that's original or unique for the project, enws-tweaks.css could contain all adjustments of stuff that's common across projects but that need a little tweak for here. Hopefully this won't be all that much once we're finished (and some stuff can hopefully be upstreamed too), so maybe having this as just a comment-demarcated section in Site.css is enough.

Conclusion: After slimming down and pruning, the rest were migrated to MediaWiki:Gadget-Site.css. --Xover (talk) 15:47, 27 April 2024 (UTC)[reply]

.poem classes[edit]

Should really have been a template with attendant TemplateStyles, but since poem is an extension tag and is being used 1) widely and 2) for creative purposes, I am not sure there are any real alternatives to a default Gadget. A lot of the uses of the extension tag would have been better off using {{ppoem}}, but it's a massive backlog that cannot be bot-converted (at best semi-automated in an interactive tool). Maybe upstream a request for TemplateStyles support in mw:Extension:Poem? In any case, it seems likely these will have to live on here for now.

The poem tag is used 120k times. This isn't worth cleaning (for now/me). Izno (talk) 22:28, 27 November 2022 (UTC)[reply]

Kept. Xover (talk) 15:46, 27 April 2024 (UTC)[reply]


#mw-hidden-catlinks[edit]

Probably not worth the cycles, since it's the responsibility of the skin in any case. Maybe get rid of it and if anybody complains we can maybe put it in enws-tweaks.css or offer instructions for a Special:MyPage/common.css workaround.

Either delete it or keep it in global CSS, you can't move it meaningfully. Izno (talk) 05:36, 26 November 2022 (UTC)[reply]
Kept, but migrated to MediaWiki talk:Gadget-Site.css. Xover (talk) 15:46, 27 April 2024 (UTC)[reply]

.page-Main_Page classes[edit]

Hmm. We probably can't target these using Template:Main page/styles.css due to scoping, so maybe they need to live on in Site.css? Do we still need all these selectors though? Most of this looks common across projects, so would be an obvious skin responsibility. No? Yes? Maybe? Need to investigate and noodle a bit it seems.

Correct, these cannot be moved. The particular selectors are appropriate, and it would be inappropriate to make this a skin responsibility. I have considered submitting a task upstream for a MediaWiki:Mainpage.css and have mentioned that on some task, but I didn't pick up any interest. (And that could be used for a full main page change that would generally be inappropriate with the access to TemplateStyles.) The benefit it would likely have would be to support wikis with multiple main pages such as Wikidata and Commons better.
The particular line at MediaWiki:Gadget-enws-tweaks.css#L-422 .page-Main_Page.action-view .firstHeading, could be removed in lieu of the same changes as at w:MediaWiki talk:Common.css/Archive 19#Main page heading. Izno (talk) 01:59, 26 November 2022 (UTC)[reply]
Yeah. I dropped the .firstHeading in favour of the interface message mechanism (on general principle more than practical importance), but I think the todo for these is more to move them to Site.css than anything else. Xover (talk) 19:27, 26 November 2022 (UTC)[reply]
Retrieved from "https://en.wikisource.org/w/index.php?title=MediaWiki_talk:Gadget-Site.css/todo&oldid=14139023"