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 setting task priorities 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.

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. :)

I would suggest waiting for container queries to be well supported so that we get basically-skin-agnostic break points, for the content use case. (See also T331227.) WMF will still need their current set but we basically won't once we have those. (We can hardcode the like 2 gadgets that actually play with the full layout e.g. the experimental Timeless and Vector responsive gadgets en.wp has.)

Ok, checked my preferences. I had neither the gadget nor the preference turned on. Turning the preference on works as expected.

I can reproduce this in either dark or light mode with safe mode on at https://en.wikipedia.org/wiki/Hand_Me_Down_World?safemode=1 in Firefox 126 for Windows 10, and noticed this a day or two ago separately on a different page.

In T330527#9848273, @gerritbot wrote:

Change #1037583 merged by jenkins-bot:

[mediawiki/skins/Vector@master] Restrict table logic to nonfloated wikitables

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

I left some comments about narrow Vector stuff when Jon made his experimental responsiveVector2022 scripts that might be some other things to consider. (Some are now taken care of for other reasons I think.)

I cannot reproduce logged in or out with Edge on Windows.

In T129054#9836050, @JScherer-WMF wrote:

I don't know why Citation drawers were made black for light mode.

I would guess to make them obvious that they're drawers and not just random citation displaying on half a mobile page. I otherwise agree that they could follow the general color theme. I would use a darker color than background-color-base, perhaps background-color-interactive.

How would folks feel about implementing some kind of media query (sorry, designer, not a web dev) that swaps certain images with their inverted counterparts in dark mode?

In the context of the various templates that spit out logos, I intend to do just that. I'll probably pull that identified logo.

This looks like a regression from T126010: Source code background spreads across the border.

Ok, filed T365926: Develop or select a dark-friendlier color palette for syntax highlighting and T365927: SyntaxHighlight's background is a bit too expansive for those two items. The second one is a regression which looks to have been caused by dark theme work.

I actually don't know what the appropriate thing to do here is. Right now it kind of looks like a fix was tried here and it didn't select the right element because of CSS elsewhere. SyntaxHighlight has this block of LESS:

In T359002#9827020, @Jdlrobson wrote:

Could we use CSS ordering to re-order the lead paragraph? If not, what would the modern way be for hoisting the lead paragraph?

I'm going to decline this boldly. The parents all got resolved, the suggested patch is now abandoned due to browser support changing (and which has now changed further two years later), and flex is non-trivial to support in LESS I think, given how the state of the art (autoprefixer) seems to go about discussing it in the context of the ancient browsers.

This was not really a reasonable fix. That span is just going to be cruft ultimately. If it's desirable to have that be applied to articles directly, there should be a template that does so.

(That one is sorted now.)

Based on the title, this may be T273745. Google has opinions on implementing a restriction as NOINDEX and robots.txt: https://developers.google.com/search/docs/crawling-indexing/block-indexing

Given the user has enabled dark mode on the mobile site

This issue was experience in Vector 22.

(I worked around the main page with an always-white background, but inverted logo of specifically the Wiktionary logo at a minimum would be good.)

In T365428#9817353, @Jdlrobson wrote:

oh I see you are talking about the border? If so I think relates to (but possibly not in scope) for T364425. Thanks for raising!

Well, I noticed it now that I knew to look for it. I don't think it works as well in dark theme as it does in light... maybe this is what color it's fading to?