I'll wait for the central switchover then.

There is an unwritten agreement among the handful of people that take care of dewiki's sitewide css/js ressources to consolidate them and this is part of it. There is almost no change on the user facing side and it's a config change that will be made anyway in the future for all projects, we're just early so we can archive the now empty https://de.wikipedia.org/wiki/MediaWiki:Mobile.css and https://de.wikipedia.org/wiki/MediaWiki:Mobile.js. I think this is a case where no formal consensus is needed.

Thanks for the heads-up, loading Print.css everywhere should be fine.

This is fixed since 1.45.0-wmf.5

This is also reproducible on desktop in minerva skin if the viewport is smaller than 640px and the search bar is collapsed.

fixed by above linked patch.

1.45.0-wmf.5 isn't live on dewiki yet

Should be resolved by https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/1134312?

See T391800 for the bug report

See T388927 - you'll have to add the link manually to MediaWiki:Sidebar. The accesskey should be gone unless you re-add it via JavaScript

Would a suitable approach be to add an exception for skin-invert and skin-invert-image in content.media-dark.less?

Due to the scroll-padding-top that is applied to the html element when vector-sticky-header-enabled is present anonymous users also jump not far enough down when following an anchor link (report).

I tried an onwiki answer, so thank you for the reply here. But IMO this could have been announced earlier and more detailed, keeping in mind that especially parts of dewiki's community are not very keen on more sudden changes at the moment after the Vector-2022 rollout two weeks ago. If this is done in fully voluntary capacity, I can understand that there are not much resources for wide communication, but with WMF budget involved there should have been room for at least a small announcement with the facts you provided here one or two weeks ago. That's all I wanted to note here.

Thanks for the links, most of the requests are based on a local discussion and also the global ones seem to come mainly from individual opinions. I don't think this counts as a good reason for the many other projects that didn't request a change and seem to be okay with the current size. Don't get me wrong, I personally don't mind a bigger thumbnail size, but I announced it onwiki and already got asked why the change will be made and where it was discussed. 'other projects discussed and requested it' doesn't seem like an appropiate answer to this. So what do I reply? If the change is rolled out globally, I would like to have a summary of the reasoning behind it with pro/cons, maybe hints to problems that could occur, etc.

I'm not really happy that an enwiki discussion 'decided' this for all other projects that now get a notice three days before the change.

Tag just means day in German. On dewiki we don't use a literal translation of the original message, so I think the result you got is fine.

This also causes class-styled table captions to loose the background color on minerva: https://de.m.wikipedia.org/w/index.php?title=Benutzer:Eichg/Spielwiese1&oldid=254997064#Farbfehler and the lack of a corresponding color rule makes the caption disappear in dark mode: https://de.m.wikipedia.org/w/index.php?title=Benutzer:Eichg/Spielwiese1&oldid=254997064&minervanightmode=1#Farbfehler

Recent feedback after dewiki switchover:
https://de.wikipedia.org/wiki/Wikipedia:Fragen_zur_Wikipedia#c-216.31.116.156-20250406070100-Hauptmen%C3%BC
https://de.wikipedia.org/wiki/Hilfe_Diskussion:Skin/Vector_2022#c-79.204.214.7-20250405135400-Daf%C3%BCr_soll_ich_Spendengeld_abdr%C3%BCcken?

I would expect a page explaining to me what "pages for logged out editors" are, not a general help/welcome page. IMO the link could be hidden if there is no such page.

The JavaScript solution was temporary until German Wikipedia switched to Vector 2022 so when the default skin switches this behaviour will go away and German Wikipedia will work consistently with English Wikipedia and other projects (E.g. no scrolling by default unless the content has been edited to support it). I can disable this sooner if that's helpful.

I can now also reproduce on Firefox, don't know what was causing different results earlier. But I'm not sure if something really changed there, though.

The missing overflow on narrow screens for the list of tallest buildings is caused by the sticky-header-multi class. It overwrites the responsive block display for small viewports with display:table and removes the x-overflow. As sticky headers are not supported with overflowing elements, enwiki's sticky header template probably does that to keep supporting the sticky header.

@kostajh the script is https://de.wikipedia.org/wiki/Benutzer:Hgzh/addIPv6range64links.js. Currently it is only used by some dewiki admins, but if it gets adapted as a native option I would welcome that. It also appends some links on the contribs page for easier access of the /64 range.

In T388521#10626214, @tstarling wrote:

@hgzh what are you doing which caused you to notice this? I assume you are not routinely typing mw.config.get("wgRelevantUserName") into your browser console.

Thanks, that makes it more clear.

To minimize disruption, the special page link will be automatically appended to the "navigation" (default) section of the main menu if MediaWiki:Sidebar was modified until shortly after the MediaWiki 1.44 release.

I actually did this already for other central stylesheets, but I thought this issue should affect also other projects and is therefore worth a central fix. As portal namespace has relatively low traffic and darkmode is not yet broadly available on dewiki, I don't see this as a high priority in our local context. But depending on the outcome here I will revisit.

In case you're interested in what the dewiki community thinks about FlaggedRevs ("Gesichtete Versionen"), you may have a look at a survey held in 2020: https://de.wikipedia.org/wiki/Wikipedia:Umfragen/Abschaffung_der_Gesichteten_Versionen_(%E2%80%9EAutorenschwund%E2%80%9C). Some participants also share thoughts about possible modifications/improvements of the status quo.

I already created the new -footer page on dewiki a few days ago. I intented to proceed exactly the way you stated above, creating first and then history-merging later. Is everything ready for the change? Then I could do this for dewiki already.

Thanks, I'll have a look at it.

Default background has been added to top-level images in T370074 - which doesn't apply to the example because it's inside an infobox.

Is there a recommendation on how to proceed onwiki?

Maybe it would be beneficial to switch 'Groups you can edit' with 'Groups you cannot edit' to have the area which you visited the special page for more on top.

In T191156#10055466, @Dogu wrote:

Before	After

This is a local wiki issue. The module got deleted after discussion some years ago, so before recreating it, there should be consensus on whether this module is needed as it brings duplication to the existing wikidata module in some parts.

Thanks for applying the background. What about images in galleries? The gallery in https://de.wikipedia.org/wiki/Butylgruppe?useskin=vector-2022&vectornightmode=1 could also benefit from this.

The scroll offset attribute you are looking for should be scroll-padding-top

Sure. I was referring to the current approach using skin-invert in codemirror and the 2010 wikitext editor.

I reported this already in T371681. The fix should go live this week.

The temporary color inversion doesn't work with os clientpref by the way.

For zebra, there is also a css solution in place, but that doesn't work in all circumstances, e.g. with rowspans or repeating table headings. Adding the white background to the image instead of the background would work, but it's sometimes better to have some kind of whitespace around the actual image to avoid an odd look in both day and night mode.

I'm not sure I understand the question. #f8f9fa is light gray, #ffffff is plain white. Both colours are used for example to create a light "zebra style". In some infoboxes they are used to distinguish key and value parts. Sometimes plain white is needed to display transparent images correctly. Editors use plain white in cases "plain white" is actually needed (white jersey in Tour de France). Sometimes it's used to have a better contrast from gray.

The default background colour in wikitable tables is #f8f9fa, not #ffffff. The background shouldn't be removed. That's an editor's choice.

Left a message on https://www.mediawiki.org/wiki/Help_talk:Lint_errors/night-mode-unaware-background-color.

I wanted to wait a bit in case there is some caching involved (don't know), but removal is already scheduled.

Is this really useful as a public error category? I don't think we want thousands of hardcoded text colors in wikitext. The dark mode WikimediaMessages stylesheet fixes almost everything there.

Thanks!

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