It is working correctly for me. Could you check something for me?

Is it possible you disabled the preference for a responsive skin on Special:Preferences? This box should be ticked by default.

Oh you said logged out.. even weirder then. Mmm

which relies on body.skin--responsive. body.skin--responsive is not activated by default.

Am I misunderstanding this statement?

This is what I'm seeing:

Seems like the cache got me, now I'm seeing the correct styling, too. At first I checked with disabling/enabling the responsive skin option and saw the difference after doing that, so I thought anons don't have the responsive mode activated by default and didn't check the presence of the class. Sorry for inconvenience.

The problem with the fullsize-expanded infoboxes on wide viewports stays, though. Not sure if it should be like that, but if not it should probably be a different task.

In T362747#9723059, @hgzh wrote:

Seems like the cache got me, now I'm seeing the correct styling, too. At first I checked with disabling/enabling the responsive skin option and saw the difference after doing that, so I thought anons don't have the responsive mode activated by default and didn't check the presence of the class. Sorry for inconvenience.

No problem just happy to learn that's working as expected! I understand what happened here now - we switched to a new module, but that module was not in cache so wasn't being applied. I'll look into this more today to get a sense of impact and see if we need an additional fix for that.

The problem with the fullsize-expanded infoboxes on wide viewports stays, though. Not sure if it should be like that, but if not it should probably be a different task.

Yep thanks for flagging! I'm fixing that today in next available backport window: https://gerrit.wikimedia.org/r/c/1020736/

I experienced this while trying to do the work on making a common site styles module in Russian Wikipedia.

I moved the styles into the gadget and soon discovered that, for whatever reason, cached views on mobile version do not get updated CSS:
https://ru.wikipedia.org/w/index.php?title=MediaWiki:Mobile.css&action=history

I had to move the stuff back into asynchronous CSS (Mobile.css) page because the asynchronous CSS gets updated but synchronous CSS doesn’t.

I think this is primarily what causes these issues: cached views for IP readers on mobile website only get CSS updates if the page itself gets updated (via edit etc.). Otherwise mobile version gets stale CSS for a week and more. Whatever is done with caching in the mobile version should be fixed because this is going to be more and more of an issue the more actual CSS capabilities of the mobile version improve (currently Mobile.css is an asynchronously loaded file).

P.S.: my comment is prompted by seeing this anonymously in English Wikipedia right now:

Change #1021518 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[operations/mediawiki-config@master] Temporarily restore wgMinervaApplyKnownTemplateHacks for cached HTML

https://gerrit.wikimedia.org/r/1021518

While this bug is the most apparent, it would be also good to explore in general what causes this problem in Minerva / mobile version in particular. I don't think the expectation of a style change should be any different on Minerva than it is on other skins. If an update is done, it should be properly propagated no matter the skin. Currently that is only the case with async CSS loaded by MobileFrontend’s JS.

This problem happens because the styles were moved to a new ResourceLoader module (ext.wikimediamessages.styles), which was not loaded on these pages before. Styles are loaded using <link> tags present in the generated page HTML, which is cached for logged-out users, and so it will be missing on some pages for up to 14 days (https://wikitech.wikimedia.org/wiki/CDN#Retention). The actual CSS that is served by /w/load.php?...&modules=ext.wikimediamessages.styles correctly includes them, but that file is not loaded on these pages.

To avoid this problem in the future, new modules must be added (with empty content) some time in advance, or the old CSS has to be kept in the old modules for some time.

For example, this is what I'm seeing at https://en.m.wikipedia.org/wiki/Mairi_Campbell (just a random page) while logged out:

@stjn I am not sure if the problem you're describing is the same. It's less obvious what could have happened there, but in your case it could actually be outdated CSS, either cached by your browser or somewhere server-side.

It's easily explained. CSS and HTML have different cache times.

We disabled the loading of these styles in Minerva and added a new ResourceLoader module in the HTML via WikimediaMessages
CSS cache is 5 minutes so old styles disappeared promptly.
HTML cache can be a few days so we are left in the situation where some pages have updated CSS but not updated HTML.

This is no different from other skins and we see similar bugs in desktop all the time - but generally they get noticed and addressed quicker because more eyes are on it.

In T362747#9727635, @matmarex wrote:

@stjn I am not sure if the problem you're describing is the same. It's less obvious what could have happened there, but in your case it could actually be outdated CSS, either cached by your browser or somewhere server-side.

I think in that case it was also what you described: new module not propagating to the HTML. It wasn’t browser-side cache because I also checked it without any cache in Firefox Focus etc. But, to be frank, I don’t think it is the same in the desktop version: I use Wikipedia anonymously extensively and I’ve both added and removed gadgets before and the change propagation on desktop is not the same as it is on mobile. I don’t exactly know the reason for it, but it doesn’t take week or two to add a new gadget module to desktop views, for instance. If anything, the changes in default modules get reflected on pages much quicker than it was with Minerva.

Desktop and mobile have different parser caches.

In T362747#9727726, @Jdlrobson wrote:

Desktop and mobile have different parser caches.

They don't any more. If you compare e.g. https://en.wikipedia.org/wiki/Mairi_Campbell and https://en.m.wikipedia.org/wiki/Mairi_Campbell, they both have the same parser cache key, as shown in the HTML comment on the page (right now, I see "Saved in parser cache with key enwiki:pcache:idhash:25315058-0!canonical and timestamp 20240413070106 and revision id 1213030049").

As far as I can tell this was changed in a11bbb9fb2fee98e81ba13ce9ec2821ab8a85ad5 a while ago.

They certainly have other differences though.

Ah that's good to know.. but varnish cache is still different, right?

I'm not sure, probably.

Change #1021518 merged by jenkins-bot:

[operations/mediawiki-config@master] Temporarily restore wgMinervaApplyKnownTemplateHacks for cached HTML

https://gerrit.wikimedia.org/r/1021518

Mentioned in SAL (#wikimedia-operations) [2024-04-18T20:25:17Z] <cjming@deploy1002> Started scap: Backport for [[gerrit:1021518|Temporarily restore wgMinervaApplyKnownTemplateHacks for cached HTML (T362747)]]

Mentioned in SAL (#wikimedia-operations) [2024-04-18T20:27:45Z] <cjming@deploy1002> jdlrobson and cjming: Backport for [[gerrit:1021518|Temporarily restore wgMinervaApplyKnownTemplateHacks for cached HTML (T362747)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Mentioned in SAL (#wikimedia-operations) [2024-04-18T20:42:32Z] <cjming@deploy1002> Finished scap: Backport for [[gerrit:1021518|Temporarily restore wgMinervaApplyKnownTemplateHacks for cached HTML (T362747)]] (duration: 17m 14s)

Was this deployed? After 4 days of moving desktop and mobile CSS to a default gadget we still get reports that some pages don't get CSS from the new gadget.
https://pl.m.wikipedia.org/wiki/Wikipedia:Kawiarenka/Kwestie_techniczne?markasread=28372271&markasreadwiki=plwiki

I could understand 24h hours cache, 48h even... But this is too much

@Nux was what deployed ? What gadget? Specifics would be helpful here :-)

Reading between the lines, my understanding is Polish is moving away from the infobox styles provided by WikimediaMessages in favor of its own gadget? If you are adding a default gadget then you are waiting for the gadget to be available in Varnish HTML. This is reported as 24hrs, but I am fairly confident there is a bug somewhere, and for practical reasons web team have always worked to the assumption that HTML cache is 7 days not 24hrs. It would be helpful to report this in a ticket tagged Traffic so we have other examples of this.

FWIW there are some people viewing Wikipedia with the safemode always enabled preference; and many Wikipedia viewers (including our official Android app) do not have support for gadgets, on so ideally these CSS rules should live in a template style. I hope this is somewhere on your roadmap?

I recently moved some common styles between mobile and desktop versions into a gadget enabled by default, and had the same problem as what @Nux is describing. The only ‘solution’ was to restore the styles in Mobile.css since that one is actually unaffected by harsh caching. But to be clear: if any Wikipedia viewers are not supporting loading the complete version of the CSS, it is their fault, not something that requires to be solved with TemplateStyles. ‘Including our official Android app’. Especially since there was previously a recommendation not to put TemplateStyles in T343131#9140322 which I don’t think should be discarded outright.

if any Wikipedia viewers are not supporting loading the complete version of the CSS, it is their fault, not something that requires to be solved with TemplateStyles

It is expected that all our content can be rendered by 3rd parties without additional JavaScript or CSS. This is definitely not their fault and it perfectly understandable that many apps may not want to execute JavaScript/CSS from a live wiki page (security being a big one). This is not just our official Android app, it also applies to Kiwix, Archive.org, and Wikiwand.

Whether an unstyled infobox meets this criteria is debatable, but please don't attribute blame to others, by using a gadget as the delivery mechanism it is expected that you as the developer have considered these factors and decided that unstyled infoboxes are acceptable.

T169027#9362252 is a great write up if you haven't seen in (in this case applied to the Graph extension).

Graph extension is a whole separate issue that was ‘solved’ once by an imperfect measure and ended up shooting everyone in the foot by that ‘solution’. I don’t think it deserves to be discussed in this task.

I am of course not talking about JS scripts being needed to view the website. But I think it is a bit insulting to the local developers to always expect their code to be subordinate just because we can’t put every barely tested CSS change into MediaWiki’s site module output. TemplateStyles was designed by its authors to have no editing requirements (and they explicitly refused to having user rights that would prevent Template CSS editing for certain groups), TemplateStyles does not have the same protection levels the sitewide CSS has unless you put it into MediaWiki namespace itself, TemplateStyles is slogging in terms of CSS support and has had no major development work outside of maintenance and stuff you needed it to do (CSS variables for the night mode). It is not the same as sitewide CSS and it does not at the moment fulfill the same function.

There is no security problem with displaying sitewide CSS in ‘safemode’, or at least there is no more problem than allowing any WMF developer to push any code with a singular +2 to their patch without considering the consequences of what this would change in site display for end-users. We have (rightly) not developed much hurdles to WMF developers (unknowingly) breaking the MediaWiki CSS every once in a while, and we don't need to make sitewide CSS something ‘unsupported’ and ‘untrustworthy’, when most of the times it can be more well-tested than some of the code that gets deployed every once in a while in Gerrit.

@Nux was what deployed ? What gadget? Specifics would be helpful here :-)

There were some patches here so I assumed the caching problem was somehow fixed :-)

Reading between the lines, my understanding is Polish is moving away from the infobox styles provided by WikimediaMessages in favor of its own gadget? If you are adding a default gadget then you are waiting for the gadget to be available in Varnish HTML. This is reported as 24hrs, but I am fairly confident there is a bug somewhere, and for practical reasons web team have always worked to the assumption that HTML cache is 7 days not 24hrs. It would be helpful to report this in a ticket tagged Traffic so we have other examples of this.

Reported: T366517

FWIW there are some people viewing Wikipedia with the safemode always enabled preference; and many Wikipedia viewers (including our official Android app) do not have support for gadgets, on so ideally these CSS rules should live in a template style. I hope this is somewhere on your roadmap?

Not on my roadmap at the moment, no. Infoboxes are complicated templates with building blocks of various types (image block, side-by-side block, chronology, data rows etc). And obviously people used infobox styles for things that are not really infoboxes... So that is even worse in practice. You can see an example of what is expected to work here (notice no header template, just class="infobox"):
https://pl.wikipedia.org/w/index.php?title=Szablon:Infobox_wiersz&action=edit

As a side note... We actually had bad rending of infoboxes since 2022. Yes, 2 years. There was a structure change that added a new paragraph in some data cells of infoboxes. You might see where this is going ;-)... To counter effects of adding a paragraph, extras CSS was added in Common.css... But of course no body bothered with Mobile.css... The problem is in the name -- Common.css is not common for all skins (I actually keep forgetting that myself). Few years passed and an option to choose custom font size was added. Font size is changed for paragraphs (.content p)... So now infoboxes on mobile actually had a mix of small and large fonts... So this time someone noticed...

Anyway. If default gadgets are not the best place for modular, global styles, then there should be some other place to keep a modular, global code. Mediawiki:Common.css might have made sense 10 years ago. Not now. Template styles are not valid solution as stjn already mentioned due to syntax limitations. IIRC template styles added up to some limits (Post-expand include size, I think). So TS is nice, but not for every case: not for widely used templates like citations and not for complicated, frankenstein templates like infoboxes.

In T362747#9855806, @stjn wrote:

Especially since there was previously a recommendation not to put TemplateStyles in T343131#9140322 which I don’t think should be discarded outright.

I checked with author @Ladsgroup and this is not a general recommendation. There is no general recommendation not to use template styles.
In the same comment he says "of course, for templates used even in 30% of page views, it's better to keep them as template styles instead".

for templates used even in 30% of page views, it's better to keep them as template styles instead

I'm afraid infoboxes don't fall into that category. Our basic infobox building block seems to be transcluded on 1,300,321 pages (and we have 1,617,733 articles). That's probably because many articles, like those about villages in various countries, are generated by bots ;-)

Let me make my stance clearer:
There are three types of template styles here:

• Templates that are used above 30% of pages in Commons: They are adding hundreds of millions of rows to templatelinks and as such we have no choice but to move them into common.css/etc. This is an official recommendation from DBA point of view to improve stability of wikis.
• Templates that are used above 50% of pages in other wikis: My personal suggestion as a random person in the internet is to move them to common.css since template styles bloat HTML of the page, adds to parsercache, templatelinks rows, requires a lot of minification (on every parse vs. a couple times a day given how aggressively we cache RL modules in every layer), adds network, adds data transfer to users, it is less efficient because of client-side caching, etc. etc.
  • Sure it has downsides, it needs to be taken into account when deciding what to move and/or those downsides should gets mitigated via ideas volunteers put above.
  • But at the end of the day, this is my personal opinion, nothing more and I think e.g. our performance God in residence @Krinkle should weigh in here. He might know something I don't :)
  • I personally don't think a default gadget would be a good idea. Common.css should be used instead.
• Anything else: Should use template styles.