Example page: w:c:Relife:Report 203. In the portable infobox, I'm using gallery to display three images of the comparable aspect ratio.
When viewed in mobile on a narrow screen, the thumbnail of the middle image ("Title") retains its aspect ratio while the first and third thumbnail images gets cropped on the top and bottom. On wider screens/windows all three thumbnail images are cropped, but the middle one is cropped less than the others so still come out taller.
My desired behavior is for all three images to show the same height in the infobox so the infobox doesn't change height when moving between images. Forcing them to be the same aspect ratio was my attempt at solving the issue for the desktop experience, but that solution was insufficient for mercury.
After investigation, it looks like for mercury, thumbnail generated for the infoboxes are cropped against their native height, even though the overall "thumbnail" image is stretched proportionally to fit the screen/window width. This makes smaller images in infoboxes look extremely awkward on mobile.
My Samsung Galaxy S7 Edge gives me 412px width in portrait mode and 732px width in landscape mode. If I start with a 250x250 square image, it's going stretch into 412x412 then crop into 412x250 in portrait, and in landscape it'll stretch into 732x732 then crop into 732x250.
This would suggest that the only way to make portable infobox image thumbnails look good (or at least semi-consistent) in mercury across a variety of mobile devices with different screen resolutions and orientations is to start the images with large amount of horizontal pixels (perhaps 1024px width to be safe?). That might mean I have to artificially stretch my images more than 3x above their original resolutions before uploading them to the wiki. Not really a elegant solution, and the image I upload would be quite pixelated, so I'd prefer not having to do things this way.
Alternately if a way to specify or hardcode max-width for mercury can be introduced and/or cap the width against the image's native width, and just have mercury center the image if screen/window is wider than the max-width, and do not crop against the image's native height, that should also allow contributers to optimize the images for a relatively consistent experience across devices of different resolutions.
We do not intend any changes at this time to the Vignette thumbnailer nor the Mercury skin to alter the automatic cropping behavior, nor to manually specify the cropping dimensions or image focal points. Suggestions for Mercury behavior are best sent via Special:Contact.
There's not really an alternative I can present. :-( The typical / expected Mercury user behavior is that they'll tap any of the thumbnails in the gallery to get a lightbox, which will be in the right scaled dimensions, and can navigate between the properly sized images using the lightbox's controls. The thumbnail is meant more as a "quick view". It may seem annoying, but consider that it is the best automated balance of parameters we can apply with that logic. For what it's worth, Facebook and Twitter have exactly the same image behavior as we do, as we have the same problem of an infinite variety of image dimensions and resolutions. It's our "best guess", and it's occasionally wrong. Seeing the images full-screen should produce the proper dimensions / scaling.
With gallery in infoboxes, there's the added annoyance of the image preview area growing/shrinking in height across images, causing the infobox content below to pop up and down (which is a bit jarring). I don't think Facebook nor Twitter has that particular problem? In particular, twitter seems to use a fixed height box to present the thumbnail for media content.
Infobox content popping up and down due to gallery image height change is actually the original issue I was trying to solve.
Update: I found a semi-workaround hack to get rid of the jarring effect, by excluding the middle image in mercury skin. The other two images have the same native dimensions so moving between them do not jar the rest of the infobox.
This is achieved by using a template to generate the middle image name inside the gallery tag, and assign that template a type which does not get rendered in mercury. A generalization of this hack would allow any components of an infobox that can be produced by a template to be omitted from the mercury infobox and be displayed for the desktop infobox only.
Sounds kind of evil, and if you rather me not use this hack on our wiki please let me know.