html.skin-theme-clientpref-night .mw-parser-output figure img

Please refine this selector so that it catches the specific figures you intend to catch. This would catch images inside figcaption and would have knockon effects at some point for having access to wikitext figure.

I imagine the dead link template is popular and maybe we should grep to see how strictly that's followed.

This is broken wikitext (for the dead link template). It should at a minimum have a space after the URL as with every other expectation of how external links work. Better, it shouldn't be in the link at all in this form, as the template emits a link itself (assuming this is a copy-paste of the English Wikipedia template). If Parsoid can see through the template expansion here, it will/should perhaps register this issue as a link-in-link error. (Or maybe that category wouldn't catch this case....)

I think adopting calendar versioning makes generally more sense with how MediaWiki is released (2024.1.X / 2024.2.X), but indeed, removing the leading useless 1 seems like a good idea to me.

I guess this is done?

The specific case of ListFiles was T270741: Long URLs (=without linebreaks) increase the width of the File History's "Comments" table cell, so that some browser zoom out a lot incidentally.

There's also a span.mw-collapsible-toggle { display: none } that would make sense to upstream.

Now fixed.

I think supporting nil as today is sufficient.

You might want to take a look at https://www.mediawiki.org/wiki/Parsoid/Parser_Unification/Cite_CSS from a year or two ago. And the subpage https://www.mediawiki.org/wiki/Parsoid/Parser_Unification/Cite_CSS/Technical_details . CSS was mass-added in many Common.css pages to support this.

Not a bug. The template sees a parameter named "Two plus two", which is not a valid parameter, which means the module outputs an empty ref tag. See https://en.wikipedia.org/wiki/Help:Template#Hints_and_workarounds for more info.

(I may be reading what the system is doing wrong, so it might also be possible to restrict the hiding with some sort of @media screen. Pretty sure it's not.)

The unreadability is caused by a local override of wikitable that is likely to have been copied at the dawn of time from English Wikipedia given it sits next to prettytable class. https://hyw.wikipedia.org/wiki/MediaWiki:Common.css#L-260 The colors identified in the extension may still merit updating, but it's not the extension's fault that page can't be read. I simply removed the color of that background and things rendered reasonably fine, so I'd guess this doesn't need changing in the extension.

Curious that it got reported.

I guess because both of the divs that make up an entity are inside an a? (The meaningful text block itself contains an a also... I think I've talked with someone about that somewhere.) Either way I think this one is approximately a false positive and/or should have the space removed, but there is no other meaningful change to be made here.

Probably the contrast issue(s) should be added to T368893: Fix Echo color contrast issues in standard theme & night mode (pt 2) and this task should be only about the missing alt text. Which actually shouldn't have alt text at all and should be set to "" rather than " ". This is a clearly decorative image, so in fact it must not have alt text. Curious that it got reported.

Kartographer should provide a color too, setting it to black or white as needed to provide appropriate contrast with the background color. (Currently this problem is not obvious on de.wikivoyage, since it overrides the color somewhere in TemplateStyles). This would resolve the Linter warnings, and would add support for dark mode, and would remove the need for those overrides. The maps themselves already do this:

Is color: inherit sufficient or do we need to drop a CSS token here?

In T354228#9431518, @Tgr wrote:

IIRC Anomie looked at the combination of W3C level and actual browser support and made the decision on a case-by-case basis.

Yeah, en.wp still nowraps its links in navbox. This does cause rendering issues at narrow widths, but not on Minerva today at least because the relevant class gets disabled.

This is a misnested tag - the code tag is an inline tag wrapping multiple paragraphs which are blocks (modulo HTML 5 framing). Linter appropriately identifies it as such:

Also, this seems like something that should be less opinionated in a CMS and otherwise dictated by a language's rules. Some default is probably reasonable, but probably this should be a config option upstream.

I guess we have a trade-off here between reading JSON on smaller screens versus making translatewiki.net happier.

Vector-2022 now removed from the supported list of skins for this gadget.

Which is expected behavior, that table is scrollable.

Turning off the float on the bar is sufficient to correct the issue. If it's necessary for something, the only thing I can think of is overflow-x: hidden. I think in this case the wide tables support now installed for Vector 22 has identified a genuine issue in the HTML/CSS used onwiki.

In T367463#9894483, @TheDJ wrote:

figure span.mw-file-description img.mw-file-element: unlinked block image, no frames

Regarding hatnotes:

• I had started a discussion on wiki about what to do about the the mobile styles a few months ago which also did some history digging for motivations and actual original design (to whit, aesthetics mostly). https://en.wikipedia.org/wiki/Module_talk:Hatnote#Mobile_styling There is a response there, but otherwise more crickets than not. There are more delta(s) listed there between original intent and currently displayed hatnotes on en.wp.
• I didn't capture specific comments from this deployment (yet?).
• Font size setting here seemed like one of the biggest problems.

Please do not change the status unless you understand what it is you're changing. See closing a task for more info.

Please either fix this task as requested or revert the problematic change sometime in the next 24 hours. My intent with filing this task 9 hours ago was that an actual fix be deployed Thursday. Guess I should have set it to UBN, because we're now up to 80ish comments onwiki. :/

The images issues are relevant to T367463, not here (same cause, possibly different symptom).

In T360386#9890771, @Sjoerddebruin wrote:

This change should have been communicated. I was very surprised to see such drastic changes to primarily the display of infoboxes on desktop.

Title is fine.

In T367463#9890708, @TheDJ wrote:

body.skin--responsive .mw-parser-output :not(table) a > img {
    max-width: none !important;
}

T116318 is an example
This is the responsive image inside a table problem. (like we also have with flags).

Yes, which is why I put the task I made about that problem in the see also. :)

In T367463#9890684, @Jdlrobson wrote:

There's a really small https://en.wikipedia.org/wiki/File:Donald_Trump_official_portrait_(3x4a).jpg on the left in the header

This is a pre-existing bug that has been a problem on mobile for years: https://en.m.wikipedia.org/wiki/Template:Donald_Trump_series that needs to be fixed on wiki. T116318 is an example, where similar problems arose in different templates. You need to put a min-width on and table column that only contains an image.

Particular quote from VPT:

it's also broken some images in infoboxes and sidebars. The images seem to have either shrunk considerably at their default size, stopped loading or completely disappeared. Examples include: Next Senedd election, 2024 United States presidential election, Template:Donald Trump series, Template:Joe Biden series, Template:Keir Starmer sidebar, Template: Rishi Sunak sidebar, Template:Elon Musk series, etc. I remember a similar change to infoboxes was made a few months ago but dropped within a day or two. Can anyone at Wikimedia provide some clarification? ThatRandomGuy1 (talk) 19:16, 13 June 2024 (UTC)

In T367462#9890629, @Izno wrote:

And also responsive images, just to document this:

it's also broken some images in infoboxes and sidebars. The images seem to have either shrunk considerably at their default size, stopped loading or completely disappeared. Examples include: Next Senedd election, 2024 United States presidential election, Template:Donald Trump series, Template:Joe Biden series, Template:Keir Starmer sidebar, Template: Rishi Sunak sidebar, Template:Elon Musk series, etc. I remember a similar change to infoboxes was made a few months ago but dropped within a day or two. Can anyone at Wikimedia provide some clarification? ThatRandomGuy1 (talk) 19:16, 13 June 2024 (UTC)

I'll file a separate task for that since it's not obvious to me what the best solution is for that.

Caused T367463: Tables with images inside them appear at minuscule size or disappear due to responsive image CSS.

And also responsive images, just to document this:

I am pretty sure this task caused T367462: Responsive Vector uses hatnote.less and infobox.less at all resolutions.

Unsigned can take a date, maybe we can futz with the wording of the template a bit when no date is provided to make it make sense with a substed revision date when the unsigned template is added. Or something like "preceding comment made by X and caught by REVUSER REVTIME". It's a change I've been thinking about also.

The surface explanation for this is that this occurs when you set display: block.

rSMIN003d9fea5be9252974f1f17b62a4af9445ced098 is the immediate cause, though you will want to research further.

In T366314#9873118, @PerfektesChaos wrote:

Regarding inline style, style="float: is not the full picture, but also float="right".

• Please see enWP (210 occurrences).

No, it's https://en.wikipedia.org/wiki/MediaWiki:Gadget-responsiveContent (you'll note the line you copy-pasted was for |skins=timeless).

The other thing that pops into mind is that floatleft/right have a clear: left/right on them and that isn't always wanted, and the uses where it's not wanted aren't always in a TemplateStyles area. Probably it's fine not to cover this case since it's not relevant the vast majority of the time when someone wants a floating thing since they're there for the reason to prevent generally the unaesthetic appearance of two stacked floating things, and could maybe be worked around with a general template if necessary.

In T366314#9871566, @Jdlrobson wrote:

With one caveat: We do intend the JavaScript to be a stopgap solution - and in future we will likely flag developer warnings where floatleft and floatright classes are not being used, and remove it entirely, so it would be a good idea to start discussions around switching over to floatleft and floatright in future on German Wikipedia and if there are any issues with the default styles we can amend them to make that a smoother transition.

This back and forth wouldn't be necessary if my suggestion from T330527#9849072 were implemented. :)