Is this issue part of any particular project? Screenshots can help here :)

In T113101#1656178, @violetto wrote:

Is this issue part of any particular project? Screenshots can help here :)

This issue can be found on all MediaWiki-based projects using default CSS, also on the Wikimedia projects. And, indeed, screenshots help, sorry for my ambiguity.

Attached:

• w:en:Jimmy Wales, small window, example of an image with caption overflowing the page by the left

• testwiki:Abián/sandbox, full window, example of an image without caption overflowing the page by the right

Yikes, that looks bad. Ping @Volker_E

Hi @abian - thanks for your question.
This is an edge case, with a mobile phone you're going to be redirected to https://en.m.wikipedia.org/wiki/Jimmy_Wales#Chicago_Options_Associates_and_Bomis
So the error on small width does only apply when you're sqeezing your desktop client browser below a certain width, which I wouldn't call a normal user's behavior (more one of a developer like myself ;) ).

Regarding the oversized images we could probably implement a max-width without having too many regressions elsewhere.
But we currently haven't set one because it should be up to the user to have as few restrictions as possible and users should also be clear that if we would go for max-width setting, and they gonna put in extra-large images, which are scaled down, you imply downloading the unnecessary data of an oversized and squeezed-down image on others and don't have the visual feedback.

In T113101#1695015, @Volker_E wrote:

Hi @abian - thanks for your question.

Thank you for your reply, @Volker_E.

This is an edge case, with a mobile phone you're going to be redirected to https://en.m.wikipedia.org/wiki/Jimmy_Wales#Chicago_Options_Associates_and_Bomis
So the error on small width does only apply when you're sqeezing your desktop client browser below a certain width, which I wouldn't call a normal user's behavior (more one of a developer like myself ;) ).

It is certainly a bad example, I only took a random article and forced this situation by squeezing my window. But there are many (many) images all around the Wikimedia projects, and MediaWiki-based projects in general, which are overflowing the page with common resolutions at the moment. I often have this problem with my netbook, which is not detected as a phone... since it's not a phone xD.

With large resolutions, users can size their windows in many different ways, and the projects should be ready for that. Even 'rare users' mean 'thousands of users'.

Regarding the oversized images we could probably implement a max-width without having too many regressions elsewhere.
But we currently haven't set one because it should be up to the user to have as few restrictions as possible and users should also be clear that if we would go for max-width setting, and they gonna put in extra-large images, which are scaled down, you imply downloading the unnecessary data of an oversized and squeezed-down image on others and don't have the visual feedback.

Extra-large images can be (and are usually) included in frames like this using overflow and overflow-x.

max-width is not a restriction because pages are not designed to be overflowed, that situation is completely undesirable (a bug) and produces an ugly and inconsistent result. And I think that overflowing the page is much worse than downloading the unnecessary data of an oversized and squeezed-down image (an issue that could be discussed and solved as well, independently).

Doesn't seem like it needs any design input.

This is one of those things that seems so simple, but in reality is really hard, because we use floating images and have lots of assumptions in existing content.
I believe the biggest challenge here was the thumbnail frame wrapping (which is one of the reasons minerva doesn't have a frame)

/* put inside a media query for narrow pages */
div.thumb {
    margin-left: 0; /*(need to override trigh/tleft margins and floats) */
    margin-right: 0;
    clear: both;
    float: none;
    max-width: 100%;
}
div.thumbinner {
    max-width: 100%;
    margin-left: auto; /* center the frame for smaller thumbnails */
    margin-right: auto;
}
img {
    max-width: 100%;
    height: auto;
    box-sizing: border-box; /* img have 1px borders, which need to be added to the 100% */
}

and then you still need to account for panoramas, audio, video, maps and other images with noresize requirements because they are already framed in a scrollable view. As so often the problem is not gonna be fixing this, but not breaking anything else that depends on it ;)

I suggest at least adding an additional class to dom for inline images, because currently it is difficult to apply styling to JUST inline images (excluding thumbnails).

This may be considered related to Accessibility because when someone improves the quality of an image it immediately breaks all the related pages with that non-thumbed image, with that weird result that make the multimedia file not easily understandable anymore for normal users or users with difficulties. For SVG images and videos in other wikis this problem is evident.

Maybe the parser could give an hint in the HTML to add a class to the image if it was generated with minimal wikitext (e.g. no class, width, etc.). A class like normal-image or something like that, easy to be customized with a default CSS rule to be applied in all the wikis (I think) without much regressions.

In T113101#5938189, @alexhollender wrote:

It would be great to document examples of where this issue is occurring. The wide images I've found (e.g. https://en.wikipedia.org/wiki/New_York_City#Boroughs) seem to respond correctly to narrowing the browser, showing a scrollbar when they run out of space:

scrolling wide image on vector.mov3 MBDownload

Note that this specific example actually demonstrates the opposite fact, because the New York City Page is not using the standard syntax to display that image:

[[File:Brooklyn Skyline (9910358874).jpg]]

They do not use that syntax because it will break the page. So they use a workaround, involving a template and a Lua module that generates this wikitext:

<div class="thumb tnone" style="margin:0 auto;overflow:hidden;width:auto;max-width:1408px"><div class="thumbinner"><div class="noresize" style="overflow:auto;direction:rtl">[[File:Brooklyn Skyline (9910358874).jpg|1400px|alt=|&#x202A;<div align=center>[[Downtown Brooklyn]] at the western end of [[Long Island]]. The [[Manhattan Bridge]] (far left) and the [[Brooklyn Bridge]] (near left) are seen across the [[East River]] from [[Lower Manhattan]] at in June 2013.</div>&#x202C;]]</div><div class="thumbcaption"><div class="magnify">[[:File:Brooklyn Skyline (9910358874).jpg| ]]</div><div align=center>[[Downtown Brooklyn]] at the western end of [[Long Island]]. The [[Manhattan Bridge]] (far left) and the [[Brooklyn Bridge]] (near left) are seen across the [[East River]] from [[Lower Manhattan]] at in June 2013.</div></div></div></div>

So, that example demonstrates that every single wiki has its own local workarounds for this bug, because images in MediaWiki are not responsive at all.

Change 793555 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/core@master] Restrict img tags to the maximum available space

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

I think this one was likely closed in error. I ran into it while working on the grid.

Change 793555 merged by jenkins-bot:

[mediawiki/core@master] Restrict img tags to the maximum available space

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

Change 803592 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/core@master] Make thumbnails responsive at low resolutions and responsive skins

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

Change 803919 had a related patch set uploaded (by Esanders; author: Esanders):

[mediawiki/core@master] Revert "Restrict img tags to the maximum available space"

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

Change 803919 merged by jenkins-bot:

[mediawiki/core@master] Revert "Restrict img tags to the maximum available space"

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

Copying over @Esanders' comment on the ticket that got this reverted:

Note that the VE surface approximately uses Parsoid HTML, which this change appears not to be compatible with. The selector seems scarily generic (.mw-parser-output img) so it should be tested against a wide range of content (e.g. galleries and other rich media extensions in both parsers) before merging it again.

The regression (T310286) that caused the patch to be reverted was this in VE:

while doing this task we should consider the editing workflows that result in images being larger than the max-width. this includes both dragging the image, or setting the value of it:

dragging	setting the value

to clarify: fixing this should include limiting the ability to make images larger than 960px in the editor

I'm not sure I agree that the limitations of a skin should be reflected in the editor. What if the wiki predominately uses a wider skin? How do we decided which wikis would get this limitation?

Another case would be if the image is wrapped in scrollable container, e.g. a panoramic photo. In that case the image would want to wider than the known page limit because the editor knows the overflow will be handled gracefully.

@Esanders understood. I've just re-worded my comment to say that we should consider the editing workflows (rather than suggesting a particular change). Is the editor aware of the skin that one is using when editing?

@Esanders maybe another way to think about this is (granted I don't understand the relationship between the editor and the skin): if Vector 2022 becomes the default skin then we can assume it's the skin being used by most projects. If people/projects using other skins want to override this limitation they can edit the skin to do so. In other words we should optimize all experiences for the default skin, and allow other skins to be a secondary concern.

On the other hand, if your team doesn't think it will be a confusing experience for people to be able to edit images to a size larger than they will be presented in read-mode, this is maybe not an issue.

Moving back to backlog for now due to other priorities.

Change 803592 abandoned by Jdlrobson:

[mediawiki/core@master] Make thumbnails responsive at low resolutions and responsive skins

Reason:

Not working on this right now

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