Page MenuHomePhabricator

Work out what to do with mediawiki.hlist
Open, Needs TriagePublic

Description

Spun out of T42062
MediaWiki core provides a RL module called mediawiki.hlist - it is loaded on the Minerva skin (mobile) and when explicitly requested.

One of the use cases would be that wikis like English Wikipedia no longer need to define (duplicate, and maintain) "hlist" styles in their MediaWiki:Common.css. This, however, presents two problems:

Open questions

  • How would the core module be loaded? Given it's not a gadget, there is no place for a "default-loaded" definition to go on individual wikis. We also don't want to load it by default everywhere as part of core. And given it's a styles module (not a JS module) lazy loading through Common.js would cause a FOUC.
  • Migration strategy. Depending on how we load it, the core implementation may need to be renamed as otherwise both definitions will apply simultaneously, which will result in style collisions and layout issues. While a suitable replacement, it probably isn't side-by-side compatible.

Migration aside, problem #1 may alone be reason enough to consider the possibility that the current approach won't solve the problem in an adequate manner given the current shape of the platform. But, if there are any ideas for making it work, I'd love to see it happen. Otherwise, we should consider removing the core module, and add minimal versions to ApiHelp and MobileFrontend separately (with their own class name).

As for the original use case, global gadgets could be a suitable solution. It'd be defined centrally, and individual wikis can enable it by default. Much like the "site-styles" gadget that exists on mediawiki.org.

Proposed solutions

  • Templates could call a parser hook function e.g. {{#addModuleStyles|mediawiki.hlist}} to load a RL style module.

Event Timeline

Jdlrobson renamed this task from Wikipedia projects should make use of mediawiki.hlist and not maintain their own .hlist styles to Wikimedia projects should make use of mediawiki.hlist and not maintain their own .hlist styles.Aug 28 2017, 9:35 PM

As I noted in T169315#3735840, mediawiki.hlist is so far very weak compared to Edokter's snippet. Starting with the fact that mediawiki.hlist has '•' as a delimiter (instead of ' • '), which creates disproportionate space if <li> elements are not followed directly one after another without any spaces. ;: lists aren't supported too.

Right now the following wikicode

<div class="hlist">
* element 1
* element 2
** subelement 1
** subelement 2
** very very very very very very very very very very very very very very very very very very very very very very very very long subelement
</div>

which is displayed the following way in enwiki

image.png (46×1 px, 5 KB)

is displayed like this on en.m
image.png (102×933 px, 8 KB)

and like this in enwiki on Minerva skin
image.png (99×936 px, 7 KB)

.hlist-separated doesn't help much, only creating misplaced bullets.

I was going to comment here but it looks like a) I agree with taking this out of core and b) I was going to say a lot of what T213239#4908027 says (or at least the top half). Maybe this should be merged to that task and turned into a "let's figure out what to do" task, especially since this task is connected up to a suspect "move JS to core" whereas hlist is not JS, and because our CSS solutions have moved on (though large wikis have lots of debt to clean).

Jdlrobson renamed this task from Wikimedia projects should make use of mediawiki.hlist and not maintain their own .hlist styles to Work out what to do with mediawiki.hlist.May 24 2021, 4:50 PM