@Jdlrobson i made some improvements to the page.

Added frameless, framed, unlinked and broken media, as well as noresize case.

Maybe we should keep frameless (aka not framed and not thumb) as the original for the short term, but if you want to tackle both at once, that's ok I guess.

Change #1043882 had a related patch set uploaded (by TheDJ; author: TheDJ):

[mediawiki/core@master] Improve responsive images and avoid for inline

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

couldn't find a good way to deal with broken media, as the parser sets an inline style for that.. So i think we better leave it alone for now, it's already bugged in that case to begin with, so shouldn't be too much of an issue.

Glossary:
span[typeof~="mw:File"] a.mw-file-description img.mw-file-element: inline image
figure[typeof~="mw:File"] a.mw-file-description img.mw-file-element: block image, no frames, aka frameless
figure span.mw-file-description img.mw-file-element: unlinked block image, no frames
figure[typeof~="mw:File/Thumb"] a.mw-file-description img.mw-file-element: thumbnail
figure[typeof~="mw:File/Frame"] a.mw-file-description img.mw-file-element: Framed (will by default size to its original size, File: syntax sizing params do nothing here)
figure[typeof~="mw:Error mw:File/Thumb"] a.mw-file-description span.mw-file-element.mw-broken-media: broken media file

At Czech Wikipedia (cs.wikipedia.org) I noticed that the changes have affected many "transportation infoboxes", using also BS templates.
For example at https://cs.wikipedia.org/wiki/%C5%BDelezni%C4%8Dn%C3%AD_tra%C5%A5_Praha_%E2%80%93_%C4%8Cesk%C3%A1_T%C5%99ebov%C3%A1, the route is broken due to pictures being smaller than before and different sizes in the same infobox. Also there are white spaces between rows and it splits the route to specific pieces. Some of the pictures are not even showing.

In T367463#9894494, @Bilykralik16 wrote:

At Czech Wikipedia (cs.wikipedia.org) I noticed that the changes have affected many "transportation infoboxes", using also BS templates.

Yes this is know, and it is what this ticket is about. These are images in a table (infobox)

The next example is at https://cs.wikipedia.org/wiki/1_(linka_metra_v_Pa%C5%99%C3%AD%C5%BEi) where all station pictures in infobox disappeared and the connection pictures on the right hand side are now placed even outside of the box.

Same, but I do note that this infobox uses white-space: nowrap around all these icons, which means it is guaranteed to break for longer content on mobile (which HAS to wrap). The community should remove that.

Out of curiosity, why are all those images linked e.g. wrapped in A tags (in comparison to https://en.wikipedia.org/wiki/Template:Routemap) - is there an on-wiki reason?
(Please also see the NOTE at the top of the task for a temporary workaround)

In T367463#9894483, @TheDJ wrote:

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

Can this selector be tightened? I'd like some day to be able to use figure in wikitext and the descendant combinator after figure is predictably sad in such a world.

In monobook and minerva skin, there is the same problem.

Adding a class="noresize" to the table seems to fix it as well? see https://en.wikipedia.beta.wmflabs.org/wiki/T367463#noresize

In T367463#9894557, @Jdlrobson wrote:

Out of curiosity, why are all those images linked e.g. wrapped in A tags (in comparison to https://en.wikipedia.org/wiki/Template:Routemap) - is there an on-wiki reason?
(Please also see the NOTE at the top of the task for a temporary workaround)

That's the default behavior when embedding files. I think there has been no reason to have them or not to have them.

In T367463#9896886, @Shizhao wrote:

Adding a class="noresize" to the table seems to fix it as well? see https://en.wikipedia.beta.wmflabs.org/wiki/T367463#noresize

Yeh I noticed this too. Ill add to the description as a short term workaround.

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

[mediawiki/core@wmf/1.43.0-wmf.9] Improve responsive images and avoid for inline

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

Change #1043882 merged by jenkins-bot:

[mediawiki/core@master] Improve responsive images and avoid for inline

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

In T367463#9894986, @Izno wrote:

Can this selector be tightened? I'd like some day to be able to use figure in wikitext and the descendant combinator after figure is predictably sad in such a world.

Ill take a look

Monobook experiences the same problem.

@Jdlrobson Please review issues below and let me know if you have any question on any of them, thanks!

Test Result - Beta/PROD

Status: ❌ FAIL
Environment: Beta/PROD
OS: macOS Sonoma 14.5
Browser: Chrome 126
Device: MBA
Emulated Device: NA

Test Artifact(s):

Test Steps

Open Wikipedia on the Minerva skin and navigate to a page with a gallery.
Scroll through the gallery images.

1.Image sizes in the following examples should be the same in Vector as Vector 2022:
https://en.wikipedia.org/wiki/Wikipedia:2009_Top_50_Report
https://en.wikipedia.org/wiki/List_of_public_art_in_the_London_Borough_of_Ealing#Ealing
https://en.wikipedia.beta.wmflabs.org/wiki/T367463
https://eu.wikipedia.org/wiki/Azala with Vector 2022 enabled
https://meta.wikimedia.org/wiki/AvoinGLAM

2.Run the QA steps in T338110 on mobile

Status	Desktop	Mobile
✅
❌	Overlaps Appearance
❌	Image splits text?	Mobile missing Donald Trump Image splits text?
❌	Different wording when comparing mobile vs desktop
✅

Thanks @GMikesell-WMF ! This is all looking good to me. Sorry I should have been clearer about a few things:

1. testing in mobile is out of scope for now. This is only aimed at desktop. All mobile issues are pre-existing and will continue to exist after this change (for now).
2. Only images are in scope - ignore tables overlapping sidebar.
3. This cannot be tested in production yet (but should be possible in 4 hrs)

@Jdlrobson OK so I will ignore the mobile issues, overlapping, and non-images for now. Are the different wording, and image split texts as designed for now and I'm just checking on the images? So for example, in possiblly 4 hours like my first gif for desktop, if it says image, there should be an actual image, correct?

Yeh the images are the main thing. They should adapt to the layout resize(unless we've said they shouldn't) .

I updated the test article to make it clearer how text should behave and to use unique images so it's clearer how it adapts.

Change #1046790 merged by jenkins-bot:

[mediawiki/core@wmf/1.43.0-wmf.9] Improve responsive images and avoid for inline

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

Mentioned in SAL (#wikimedia-operations) [2024-06-18T21:03:07Z] <jdrewniak@deploy1002> Started scap: Backport for [[gerrit:1046790|Improve responsive images and avoid for inline (T367463)]], [[gerrit:1047155|Fix codex link styles overriding other link styles (T367844)]]

Mentioned in SAL (#wikimedia-operations) [2024-06-18T21:07:47Z] <jdrewniak@deploy1002> jdrewniak, jdlrobson: Backport for [[gerrit:1046790|Improve responsive images and avoid for inline (T367463)]], [[gerrit:1047155|Fix codex link styles overriding other link styles (T367844)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Mentioned in SAL (#wikimedia-operations) [2024-06-18T21:09:33Z] <jdrewniak@deploy1002> Started scap: Backport for [[gerrit:1046790|Improve responsive images and avoid for inline (T367463)]], [[gerrit:1047155|Fix codex link styles overriding other link styles (T367844)]]

Mentioned in SAL (#wikimedia-operations) [2024-06-18T21:13:59Z] <jdrewniak@deploy1002> jdlrobson, jdrewniak: Backport for [[gerrit:1046790|Improve responsive images and avoid for inline (T367463)]], [[gerrit:1047155|Fix codex link styles overriding other link styles (T367844)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Mentioned in SAL (#wikimedia-operations) [2024-06-18T21:26:07Z] <jdrewniak@deploy1002> Finished scap: Backport for [[gerrit:1046790|Improve responsive images and avoid for inline (T367463)]], [[gerrit:1047155|Fix codex link styles overriding other link styles (T367844)]] (duration: 16m 33s)

@Jdlrobson I noticed this behaviour btw. Images that are not aligned similar to the preceding image, do not clear the preceding content, and thus they size to the space that 'remains', as it can't reduce size equally between the images.

This shouldn't happen very often like this, because you need to spend all your horizontal width with two images with differing alignments and having a 700px image that isn't using the wide image template or something like that isn't that common. The smallest dimensions this can happen are least 550px or so of available space, so 300px on one side and more than 250px on the other side, which shouldn't be a very common layout. And If you have less available space that situation is likely to hit the forced clearing due to mobile.

Still something to keep an eye on, esp as there is a long term desire to up the thumbnail size to 300px, and that would result in hitting this situation a lot faster I think. It might be worth thinking about some new layout options for the future at some point.

@Jdlrobson Can you review the gifs and screenshots if these errors are what you are talking about or if these are different issues not about this task?

UPDATE: Due to be ing out of scope or working as designed as mentioned in T367463#9911209, these will now be passed

Test Result - Beta/PROD

Status: ✅ PASS
Environment: Beta/PROD
OS: macOS Sonoma 14.5
Browser: Chrome 126
Device: MBA
Emulated Device: NA

Test Artifact(s):

Test Steps

Open Wikipedia on the Minerva skin and navigate to a page with a gallery.
Scroll through the gallery images.

1.Image sizes in the following examples should be the same in Vector as Vector 2022:
https://en.wikipedia.org/wiki/Wikipedia:2009_Top_50_Report
https://en.wikipedia.org/wiki/List_of_public_art_in_the_London_Borough_of_Ealing#Ealing
https://en.wikipedia.beta.wmflabs.org/wiki/T367463
https://eu.wikipedia.org/wiki/Azala with Vector 2022 enabled
https://meta.wikimedia.org/wiki/AvoinGLAM

2.Run the QA steps in T338110 on mobile

Status	Desktop
✅
✅	White boxes
✅	2 small images with the tiger jumps back and forth to big image and small when making the screen smaller Trump info box is still white
✅	Images layout is off when decreasing screen size?
✅

@GMikesell-WMF these all look like they are working as expected or out of scope! Thanks!

For Tech News, please could someone confirm or describe what exactly needs to be communicated? I'm uncertain if it's essentially just informing everyone about a temporary bug that was fixed, or if there's any followup edits that might (or do) need to made by editors. If it's the former, I would hesitantly propose using this wording:

• Two weeks ago there was a problem with the displayed size of some images that are used within tables. This was fixed last week.

I think you can reuse https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Tuesday_19th_update

Ah, right, then I believe this is essentially covered by the mention in last week's Tech News. Thanks.

Hello, I reported T368137, I noticed last week's Tech News only afterwards.

@Jdlrobson Hi! Can you please take a look at this template, how can I fix it?
https://ru.wikipedia.org/wiki/Шаблон:Сообщение_ХС

I see that this is still happening here: https://eu.wikipedia.org/wiki/Wikipedia:Bost_euskarriak. What should we do to improve that? Should we find every affected page and solve it manually?

@Theklan - yes this needs to be fixed on wiki. You now need to add the noresize class to a parent element or change the images so they don't link to the file page (see the note at the top of the task description)

In T367463#10021736, @Theklan wrote:

I see that this is still happening here: https://eu.wikipedia.org/wiki/Wikipedia:Bost_euskarriak. What should we do to improve that? Should we find every affected page and solve it manually?

@Theklan the images in this table use alignment (in this case "left"). This turns them into block elements that automatically receive responsive sizing. Simply removing |left will turn them into inline image (no alignment whatsoever) and then they should not have this problem.