Page MenuHomePhabricator

Images should be responsive in Vector and restrained to a max-size.
Open, MediumPublic

Description

All images wider than #content overflow. I cannot figure out why this issue has not been solved after so many years.

I think one solution could be applying...

max-width:100%;
height:auto;

... to all images, or to all images inside relevant containers like #content.

Event Timeline

abian created this task.Sep 18 2015, 9:50 PM
abian raised the priority of this task from to Medium.
abian updated the task description. (Show Details)
abian added projects: Design, WMF-Design.
abian added a subscriber: abian.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 18 2015, 9:50 PM
abian set Security to None.Sep 19 2015, 3:35 PM
abian added subscribers: MNguyen, violetto.

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

abian added a comment.Sep 19 2015, 5:17 PM

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

Yikes, that looks bad. Ping @Volker_E

abian raised the priority of this task from Medium to High.Sep 23 2015, 7:21 PM

Yikes, that looks bad. Ping @Volker_E

I think so, raising priority...

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.

abian added a comment.Oct 1 2015, 10:48 PM

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

Volker_E removed a subscriber: violetto.
Jdlrobson renamed this task from Prevent images from overflowing the page to Prevent images from overflowing the page when resizing browser on desktop .Jun 21 2017, 12:28 AM
Jdlrobson lowered the priority of this task from High to Low.
Jdlrobson added a project: Vector.
Jdlrobson renamed this task from Prevent images from overflowing the page when resizing browser on desktop to Images should be responsive in Vector and restrained to a max-size..Jan 15 2020, 6:27 PM
Jdlrobson raised the priority of this task from Low to Medium.
Jdlrobson added a subscriber: Jdlrobson.

In new Vector if we limit the size of the article this is going to be a problem.

Jdlrobson moved this task from Needs triage to Needs Design on the Vector board.Jan 15 2020, 6:28 PM

Doesn't seem like it needs any design input.

TheDJ added a subscriber: TheDJ.EditedJan 17 2020, 1:10 PM

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

TheDJ removed a subscriber: TheDJ.Jan 29 2020, 11:29 PM
valerio.bozzolan added a comment.EditedFeb 24 2020, 7:01 PM

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.

Demian added a subscriber: Demian.Feb 25 2020, 4:46 AM
ovasileva raised the priority of this task from Medium to High.Feb 25 2020, 8:18 AM

This will need to be addressed as part of the work on fixed width.

alexhollender removed alexhollender as the assignee of this task.Mar 3 2020, 6:21 PM
alexhollender added a subscriber: alexhollender.

per a discussion I had with @Jdlrobson I'm unassigning this from myself.

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:

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:

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.

ovasileva lowered the priority of this task from High to Medium.Apr 28 2020, 2:10 PM
Jdlrobson edited projects, added Vector (Responsive-Vector); removed Vector.
Xover added a subscriber: Xover.Jun 7 2020, 9:06 AM