This doesn't seem to impact Vector, though I'm not sure if Vector has gotten small resolution image treatment yet (which I presume is the utility of the CSS of interest).

So, here's a workaround for the time being I guess: add another div internal to the flex item to contain the image and set a width on that element.

<div style="display: flex">
  <div class="flexy-item">
    <div style="width: 40px">[[File:Example.jpg|40px]]</div>
  </div>
  <div class="anotherflexy-item">...</div>
</div>

Though this doesn't seem to work if one of the float classes has been set on the element - back to small again.

@stjn found setting flex works to fix this also:

<div style="display: flex">
  <div class="flexy-item" style="flex: 0 40px">[[File:Example.jpg|40px]]</div>
  <div class="anotherflexy-item" style="flex: 1">...</div>
</div>

Probably the best solution without changing more.

This is practically the same as with tables (there's a ticket somewhere). If there is no set min-width and you enable responsive images (Which is basically what that mobile/minerva code does) then the smallest valid size is like 1px. Best is to set a min-width on anything you don't want to be smaller than a certain size.

I suggest this is fixed in the template.

There is already an inline style padding-right: 0.5em; on the element and a min-width: 20px; could be added there to prevent the shrinking.

I don't see any good generic solution, and the problem that rule is solving seems a greater to one to solve than posed by this use case.

Related ticket: T116318: Images in tables are too small

In T282588#7228625, @Jdlrobson wrote:

I suggest this is fixed in the template.

There is already an inline style padding-right: 0.5em; on the element and a min-width: 20px; could be added there to prevent the shrinking.

I don't see any good generic solution, and the problem that rule is solving seems a greater to one to solve than posed by this use case.

I'm fine with "document this behavior somewhere" as a resolution, maybe "make pages better for mobile" since eliminating presentation tables is the use case that presents this problem task.

That said, I would at least like to get the !importants removed. The comment that seems to implicate the !important (to wit, "Prevent inline styles on images in wikitext") in rSMIN/resources/skins.minerva.base.styles/content/images.less don't make sense to me because you in fact cannot set inline styles on images (specifically img) in wikitext today, only classes (which I think are on the parent div/figure/span anyway), at least without TemplateStyles, which will be a deliberate override I suspect:

		// Prevent inline styles on images in wikitext
		// Note we restrict to img's to avoid conflicts with VisualEditor shields
		// See bug T64460
		// due to lazy loading images we also must consider imgs inside noscript tags (T191893)
		a > img,
		noscript > img {
			// make sure that images in articles don't cause a horizontal scrollbar
			// on small screens
			max-width: 100% !important;
	
			// Note height auto is only applied to images. Not neeed for the lazy-image-placeholder which is
			// a gray box and will cause reflows.
			height: auto !important;
		}

Maybe there's another reason for !important, but that shouldn't be the only one then. (Maybe the reason is to 'make it difficult for TemplateStyles', but TStyles can still get over the hump if it wants.)

The !importants are there for good reason. Inline styles will take precedent over any CSS rule.

Consider the God article and this image at a low resolution:

Without !important, while the max-width will still apply (because this image doesn't set a max width, the height auto will not apply leading to an image stretched vertically:

So, that's why the !importants are here. Ideally wikitext would not generate img tags with style attributes, and instead inline the CSS in a style tag or use the width and height attributes (although using height and width means we'd only be able to express image dimensions in pixels).

Wikitext can't generate img tags with style attributes though.

In T282588#7539502, @Izno wrote:

Wikitext can't generate img tags with style attributes though.

I'll have to look into this some more obviously then :-)
It's possible the style attributes are needed for lazy loading images.

Lazy loaded images set style via width and height. Not sure why though, the width and height attributes are being set as well..

Edit:

<span class="lazy-image-placeholder" style="width: 220px;height: 210px;" data-src="//upload.wikimedia.org/wikipedia/commons/thumb/a/ab/Vue_circulaire_des_montagnes_qu_%E2%80%98on_decouvre_du_sommet_du_Glacier_de_Buet%2C_from_Horace-Benedict_de_Saussure%2C_Voyage_dans_les_Alpes%2C_pr%C3%A9c%C3%A9d%C3%A9s_d%27un_essai_sur_l%27histoire_naturelle_des_environs_de_Geneve._Neuchatel%2C_l779-96%2C_pl._8.jpg/220px-thumbnail.jpg" data-alt="" data-width="220" data-height="210" data-class="thumbimage"></span>

the placeholder has styles set (because otherwise we cannot reserve space). The lazy loaded image script then copies these styles and applies them to the <img> element. These should probably be filtered out as it already sets width and height attributes.

That would probably work yes (on that assumption that inline style of width and height can never be set by wikitext)