Page MenuHomePhabricator

Gadget CSS should be applied after Site styles
Closed, DeclinedPublic

Description

The proper load order should be site.styles (Site CSS), ext.gadget.... (Gadget CSS), user.styles (User CSS). What is is currently (Gadget CSS, Site CSS, User CSS):

<link rel="stylesheet" href="/w/load.php?debug=false&amp;lang=en&amp;modules=ext.gadget.Blackskin%2CWatchlistBase%2CWatchlistGreenIndicatorsMono%2Ccharinsert-styles&amp;only=styles&amp;skin=monobook"/>
<link rel="stylesheet" href="/w/load.php?debug=false&amp;lang=en&amp;modules=site.styles&amp;only=styles&amp;skin=monobook"/>
<link rel="stylesheet" href="/w/load.php?debug=false&amp;lang=en&amp;modules=user.styles&amp;only=styles&amp;skin=monobook&amp;user=Dispenser&amp;version=0lguk4o"/>

Related: T147667

Event Timeline

Dispenser renamed this task from Gadget CSS should be applied after Common.css to Gadget CSS should be applied after Site styles.Apr 10 2018, 11:47 PM
Dispenser changed the task status from Open to Stalled.
Dispenser updated the task description. (Show Details)

@Dispenser Please specify the wiki+page and/or full url at which you can consistently see this, and whether it applies to logged-in, logged-out, or both. If logged-in only, does this require specific user preferences to be set?

Krinkle changed the task status from Stalled to Open.Jun 16 2018, 3:39 PM
Krinkle triaged this task as High priority.
Krinkle moved this task from Inbox to Confirmed Problem on the MediaWiki-ResourceLoader board.
Krinkle added a project: Regression.

From the Green on black skin, it was brought up at Village Pump (screenshot) after I removed the workaround for T147667. Apparently locals styles in MediaWikiMonobook.css are applied after gadget styles.

Monobook.css

.ns-0 div#content,
.ns-0 div#p-cactions li a:hover, .ns-0 div#p-cactions li.selected a, 
.ns-0 div#content div.thumb {
	background-color: white;     /* Set back to white for articles */
}

Gadget-Blackskin.css with higher specificity workarounds

body.skin-monobook.ns-0 div#content,
body.skin-monobook.ns-0 div#p-cactions li a:hover, 
body.skin-monobook.ns-0 div#p-cactions li.selected a, 
body.skin-monobook.ns-0 div#content div.thumb {
	background-color: #000000;     /* Set back for articles */
}

I can reproduce this when enabling any "style module" gadget on en.wikipedia.org (such as "Display green … watchlist").

Resulting in the following HTML payload:

<script>
mw.loader.load(["mediawiki.searchSuggest",,"ext.eventLogging.subscriber",,"ext.centralNotice.geoIP",</script>
<link rel="stylesheet" href="/w/load.php?debug=false&amp;lang=en&amp;modules=ext.echo,…,skins.vector,…"/>
<script async="" src="/w/load.php?debug=false&amp;lang=en&amp;modules=startup&…"></script>
<meta name="ResourceLoaderDynamicStyles" content=""/>
<link rel="stylesheet" href="/w/load.php?debug=false&amp;lang=en&amp;modules=ext.gadget.WatchlistGreenIndicators&…"/>
<link rel="stylesheet" href="/w/load.php?debug=false&amp;lang=en&amp;modules=site.styles&…"/>
<link rel="stylesheet" href="//meta.wikimedia.org/w/load.php?debug=false&amp;lang=en&amp;modules=ext.globalCssJs.user.styles…"/>
<link rel="stylesheet" href="/w/load.php?debug=false&amp;lang=en&amp;modules=user.styles…"/>
<meta name="generator" content="MediaWiki 1.32.0-wmf.12"/>

Strictly speaking, this does not appear to be a regression from T147667, which caused gadget styles to be loaded alongside other style modules (in the primary stylesheet).

It is:

  • Still in its own stylesheet.
  • Still after core and skin styles.
  • Still after the ResourceLoaderDynamicStyles marker.
  • Still before any "user" group styles.
  • Still in the "site" group for styles.

However, within the "site" group, ext.gadget sorts before "site" and there is nothing enforcing "site" from being before "ext.gadget.*".

I've looked at how this used to be and at similar feature requests and use cases and believe this should be declined.

We have never supported controlling the order of stylesheets between gadgets (e.g. gadget B being before gadget A), and we've done as much as we can to get exactly where we are now, which is that Common.css is essentially a gadget (internally "module of wiki pages", or ResourceLoaderWikiModule). This has also made it easy to convert Common.css on a wiki to being an actual gadget (such as on www.mediawiki.org).

I'd recommend that in the rare case of Common.css and a gadget needing to style the same element that we use the same mechanism as what we use for when two gadgets do that (such as WatchlistBase and WatchlistGreen).

Specifically, that one style must be explicitly stronger than the other. The order cannot be controlled or assumed within this particular category of styles.

I understand that it is not ideal to add non-semantic weight to a CSS selector, but it is at least consistent to how we approach this problem in other areas. For example,

  • between components within MediaWiki core,

*components part of different Extensions,

  • and indeed for two site-wide wiki pages (including MediaWiki:Gadget-*.css and MediaWiki:Common.css).

If this becomes a significant blocker to progress, or if we find that the workaround does not work in some cases, we may want to consider a dedicated solution to control the load order within groups. But at this point, there is not something we can do within our system to easily change the load order.