There shouldn't be any stylistic rules in infobox.less, the additional padding was always breaking tables on minerva causing weird look and overflows when used with fixed inline width. Time to get rid of it and let TemplateStyles do it where wanted.

Hm, creating an y-scroll on the parent element indeed fixes the stickyness of the table header and I know it's probably the only way to maintain the sticky header with horizontal scrolling in a css-only way, but I'm not sure if this really creates a good ux:

• if the table height is smaller than the viewport (see https://de.wikipedia.org/wiki/Walensee which has a rather short table with sticky headers) there will be a lot of additional whitespace that fills the remaining viewport height.
• having many elements with vertical scrolling makes the page look cluttered, especially when at some point there will be horizontal and vertical scrolling combined.
• this is based just on my personal experience, but I find it quite annoying having two vertical scrolls in one page especially where the 'inner' vertical scroll size exceeds my viewport.

Maybe the sticky header issue (T366314#9873064) could be another task.

The italics rule is not present anymore in the current stylesheet.

Thanks Izno for filing the documentation task, I was about to suggest something similar if the floatleft/right classes will become mandatory for positioning. I guess the non-javascript version will be to directly output the wrapper div from parser?

The float-left and float-right classes are quite old, introduced in January 2007 (https://de.wikipedia.org/w/index.php?title=MediaWiki%3ACommon.css&diff=25858783&oldid=25637989) when sortable tables were new and it became clear that the now-deleted Template:Prettytable that was used for common template styling was too unflexible as it didn't support adding new classes for tables (Template:Prettytable had siblings Template:Prettytable-L and Template:Prettytable-R that did the floating stuff).

Side note: with https://pl.wikipedia.org/w/index.php?title=MediaWiki%3AGadgets-definition&diff=73889807&oldid=73887321 and directly removing the code from mobile.css in https://pl.wikipedia.org/w/index.php?title=MediaWiki:Mobile.css&diff=prev&oldid=73890354 you will probably be running into caching issues for anons like in T362747, so maybe it makes sense to postpone opting out of the global styles until the cache has cleared.

See https://www.mediawiki.org/wiki/Extension:WikimediaMessages#Site_admin_helper on how to disable WikimediaMessages styles locally. It's the infobox bit.

Maybe related to T274359

For now this is intended behavior, see T361934#9692764

With the upcoming dark mode, TemplateStyles stylesheets get bigger and also more complex (see this discussion at dewiki for an example). It would be nice to have TemplateStyles abilities extended with some more modern css. Browser support shouldn't be that much of a problem anymore five years after this task was created.

It's fine now, could be marked as resolved IMO

Nice to see that a "fix" (it's not really a bug) is on the way. Thanks for having a look at this.

Before I start using this onwiki: is there a risk of this later being revoked following the security review?

For using table syntax inside of a parser function, you need:

{| class="wikitable"
{{#if: {{{param|}}}
  | {{!}} foo {{!}}{{!}} bar
}}
|}

which renders as two table cells if param is set.

{{!}} needs to be treated as part of the table syntax for usage in parser functions.

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.

Don't know if that helps for investigation, but while the "stash parsoid html" error occurred today, I also got an OAuth E004 missing request token error when trying to login to Phabricator. It worked again the same time as the parsoid error disappeared.

This happened also in dewiki for every page and for discussiontools, now seems fine again.

That's the same as T361940 which already has a connected patch to revert the change.

Other revisions without text change like protections and moves are also affected.

Could it be that FlaggedRevs removes the tags applied by core? I saw something in maybeMakeEditReviewed but I don't fully understand everything there.

There are four changes that got the tag ("Zurückgesetzt" is reverted):

• https://de.wikipedia.org/w/index.php?title=Jassir_Arafat&curid=2493&diff=243768744&oldid=243066759
• https://de.wikipedia.org/w/index.php?title=Lanterne_Rouge&curid=3723391&diff=243768858&oldid=243768411
• https://de.wikipedia.org/w/index.php?title=Blixa_Bargeld&curid=61609&diff=243769643&oldid=243621320
• https://de.wikipedia.org/w/index.php?title=Fallschirmspringen&curid=30040&diff=243782947&oldid=243482341

Can confirm this in template namespace that also has FlaggedRevs activated. https://gerrit.wikimedia.org/r/c/mediawiki/extensions/FlaggedRevs/+/1015176 has changes to FlaggedRevs and reverts but seems unrelated to me at first glance.

Yes, the content looks different depending on skin (and that's okay), but my impression is that especially the wikitable styling is pretty much the same across all wikimedia deployed skins, and because the background styling is already in ResourceLoader skin module, it makes sense to also apply the background consistently. If from a design point of view it makes sense to have some kind of visual connection between table and caption (I don't know), then I'm fine with it, but it should be considered that some tables make use of completely different background colors in the entire table which would leave the caption area as the only one with the initial background - then the visual connection seems rather weak and random to me.

This should be a duplicate of T361775

I think this is caused by https://en.wikipedia.org/wiki/User:Headbomb/unreliable.js which applies #ffdddd background color as inline style to a.external when a link to wikipedia gets matched. plainlinks overrides the background color, but the inline style persists and gets chatched by the night mode rule.

I think this got fixed by https://gerrit.wikimedia.org/r/c/mediawiki/core/+/833413, right?

Thanks a lot @matmarex and everyone else involved!

Thanks for clarification, then it's the additional styling causing the issues. We're discussing approaches for fixes at https://de.wikipedia.org/wiki/Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#Ge%C3%A4nderte_%C3%9Cberschriftenstruktur but it doesn't seem so easy at first glance - maybe you have an idea, your input would be appreciated. For dewiki's main page I did this: https://de.wikipedia.org/w/index.php?title=Wikipedia%3AHauptseite%2F%21box&diff=240191659&oldid=213295348

Since the update of 1.42.0-wmf.9 it seems like DiscussionTools already applies the heading html transformation - I had to hotfix dewiki's main page as it looked broken. You can see the broken look still on other pages like https://de.wikipedia.org/wiki/Wikipedia:Autorenportal or https://de.wikipedia.org/wiki/Hilfe:%C3%9Cbersicht. I'm also not sure why DiscussionTools is active on these page(s), though.

D is the marker of a wikidata item and K stands for minor edit in German.

Caused by T350443? Database seems to have high lags

Sorry, I restored the test case and updated my comment.

Should't the category be named wikihiero-usage-tracking-category?

The DOM looks odd, we have div and p inside span now and the mw-fr-reviewformlegend span got an 'additional' cdx-card__text id which should be in class= I guess.

reproduced here using the original article contents:

Thanks! Task should be resolved then.

jobs are all moved to kubernetes, however it seems there are 16 running jobs on GridEngine left that are stuck, don't know if and how I can abort them.

Done.

Thanks for having a look on this, we will check on thursday if there's still a problem.

I edited the local messages; don't know if jqueryMsg getting enhanced is likely, if not the task could be closed.

This is T308398 I guess

dewiki also uses some of the thumb classes (thumbinner, tleft, tright, thumbcaption) in templates and article text. Will they be preserved for a migration period? And is it possible to give a complete list of classes that will be changed/renamed?

Came here as a part of the ongoing discussion in dewiki, IMO the talk page behaviour should be consistent over all talk pages; enabling topic containers on NEWSECTIONLINK pages could be an extra option.

No problem, the maintainer of our most important template tool is informed and I'll check what has to be changed locally onwiki.

Okay, thanks. Thought there would be another announcement before it starts, but I haven't followed this process that close so I may have missed some previous messages and deadlines.

Has writing the old colums already stopped on dewiki? There are currently ~14000 empty ones via https://quarry.wmcloud.org/query/66578; by-article example: https://quarry.wmcloud.org/query/66579

Thanks! Another observation I made: the message also appears on talk page redirects with ?redirect=no (e.g. https://de.wikipedia.org/w/index.php?title=Modul_Diskussion:Radsportplatzierungen&redirect=no). This should also be avoided IMO.

I like the idea, but from an UX viewpoint it would probably be better to have the clear button next to the reason input field.

Should be resolved with https://gerrit.wikimedia.org/r/772046

The move form tranformation is done by https://de.wikipedia.org/wiki/MediaWiki:Gadget-old-movepage.js

Seems like the same as T225366

I think the problem is caused by monobook's conversion to responsive/non-responsive. .monobook-capitalize-all-nouns becomes body:not(.skin--responsive) .monobook-capitalize-all-nouns resp. body.skin--responsive .monobook-capitalize-all-nouns and that doesn't match anymore as .monobook-capitalize-all-nouns is a class assigned to body.

Just for the record: dewiki uses it ~2000 times: https://de.wikipedia.org/w/index.php?search=insource%3A%2Fmw-datatable%2F&title=Spezial%3ASuche&go=Artikel&ns0=1

Seems like it doesn't work. Everything is lowercased at https://de.wikipedia.org/wiki/Wikipedia:Hauptseite?useskin=monobook

Yes, the pages are looking fine again. Thank you!

for dewiki main page, it seems like the class(es) are stripped from the h2 elements and replaced by ext-discussiontools-section which leads to the broken look.

The behaviour of the watch checkbox seems to be inverted. In addition to the effect mentioned by Count Count: if you try to protect a currently unwatched page, the 'watch page' checkbox is set by default.

This recently came up again on the administrator's noticeboard on dewiki; the recreate-message appears after the editnotices and the newarticletext that is quite long (https://de.wikipedia.org/wiki/MediaWiki:Newarticletext-0) so in the end will only be shown after scrolling down which most users won't do. It should at least be moved to the top of the flyout as it is actually a warning rather than just information messages like newarticletext.

Side effect to this: both revisions are shown on Special:Undelete (with correct summary and tags), but clicking on one timestamp always leads to the same text.

dewiki has made the change today. I think we found a clean and sustainable solution.

Has this been reverted? dewiki seems to have the proportional font back. In addition, diffs shown in unreviewed revisions of a page (FlaggedRevs) did not use the monospaced font even before today.

Some new cases today:
https://de.wikipedia.org/w/index.php?title=Wikipedia:Fragen_zur_Wikipedia&oldid=198231736#Verschiebung_funktioniert_nicht,_Seite_ist_auf_einmal_ungesichtet

@matej_suchanek @Toni_Mueller that could be the reason. I found a link on dewiki's administartor's noticeboard containing enhanced=1 added on the day when the first complaints popped up. An user also already seemed to be on the right track.

probably the same issue led to inquiries at dewiki: https://de.wikipedia.org/wiki/Wikipedia:Technik/Werkstatt#Fataler_Ausnahmefehler_des_Typs_%E2%80%9ELogicException%E2%80%9C