Page MenuHomePhabricator

Create hierarchy of classes for styling core content components
Closed, DuplicatePublic


Basically we need a hierarchy of classes for elements like the ToC, catlinks, tables, and other boxes that can be consistently reused across core, extensions, and even appropriate content templates, where we have some sort of generic box type class as the top level that just makes the main container for all of these, and then some more specific things to apply to various categories of types like warnings, media, tables, etc.

Someone will need to actually look into what all we actually have in order to come up with a proper solution here, but once done, this should allow skins to style a specific set of elements without worrying about missing things, and extensions to implement consistent styles with considerably less work as well.

Why this is a problem

Currently we just have a mess of redundant and/or inconsistent styles even in major skins like Vector. Core has separate styles for wikitables, tables of contents, catlists, etc, as part of a module that also styles content headers and a bunch of other stuff (mediawiki.skinning.interface), but also styles other similar objects like datatables and metadata tables in totally other modules. While this separation of modules isn't necessarily an issue, the separate styles and lack of any common classes between them is, so to update any of them, they all need to be updated individually. To complicate things even further, there are many other objects, such as the mw-warnings, that aren't styled consistently at all and really should be for proper site cohesion. Extensions, too, simply need to either mimic these styles or attempt to reuse classes that were simply not meant for that, like the toc, because there are just no other options.

And that's for skins using the default MediaWiki styles. For any new skins using different styles (most modern ones, really), there is just no way to catch all of this besides simply catching all of this by defining selectors and special handling for a hundred different things that should just be the same to begin with. Visual style compatibility with extensions is hopeless (unless manually implemented on a per-extension basis), because there is just no standard for extensions to implement to make this otherwise. Even onwiki content suffers because as much as we would like our infoboxes and navboxes to look visually consistent with the rest of the site, there's nothing for these to inherit either. (Also a huge problem for making things like night mode work, because even if the skin supports it, the navigation templates can't inherit it...)


Things in core (will need to be supported, and then migrated):

  • toc
  • filetoc
  • mw_metadata
  • catlinks
  • wikitable
  • datatable
  • thumbs
  • permissions-errors
  • mw-warning and all the random variants like mw-warning-with-logexcerpt (these would need basic box styles, plus the ability to apply specific colours)
  • Other things
  • (stuff like fieldsets also should arguably be here, but forms specifically are generally OOUI, so those would just be a concern of if this potentially can be reused/inherited by that as well...)

Extensions usually try to reuse this stuff, but things adding any wildly new stuff tend to have to implement their own styles entirely (actually give them the option and they'll come around eventually):

  • Comments and other discussion extensions
  • Translate
  • wikidata stuff
  • I dunno, there's a lot of extensions out there...


  • infoboxes
  • navigation templates
  • Any other random template that's not actually specifically content, or for the same kind of content as the rest of it

Developer notes

For this to work, it will probably require some PHP scaffolding to model what a component actually is.
Prior art:

Event Timeline

While mixins can and likely should be used to handle a lot of the specifics, we still need the actual classes to be used commonly so they can be applied wiki-side or in weird other uses as well.

Note that for the purposes of T217158, this is considered the next step after that, but does not depend on it. In particular we should consider how that might affect the module interactions if we wind up doing this first/concurrently in order to minimise the amount of work between the two.

Dinoguy1000 subscribed.

Feel free to disagree, but this certainly feels like an Epic task to me...

Jdlrobson subscribed.

Am pretty sure this is a duplicate of T89981.
At least they share the same goals.