@TheDJ what is our concern with enabling responsive behaviour on frameless images - are there some examples of these in the wild that would be broken by applying the responsive behaviour?

My concern is mostly their sizing inside tables and inside display:flex containers etc. going to 0x0.
And as inline images are often used as building block inside templates (infoboxes etc, self made maps with overlays etc) they have a lot of diverse usecases. This will be difficult to verify compatibility with in all wikis.

Here's an example I found in the wild: https://en.wikipedia.org/wiki/Opinion_polling_for_the_2024_United_Kingdom_general_election (I assume this would be considered frameless?)

Note: This also doesn't work as expected for me and doesn't degrade gracefully - I don't see the switcher when logged in without any reason why

Looked into the table/flex problem a bit.

The only way I can really counter this for tables, was with complex selectors in :not() but that does complicate the selectors quite a bit.

@supports(selector(:not(table img))) {
	span[ typeof~='mw:File' ] img.mw-file-element:not(table img),
	span[ typeof~='mw:File/Frameless' ] img.mw-file-element:not(table img) {
	    max-width: 100%;
	    height: auto;
	}

	.noresize span[ typeof~='mw:File' ] img.mw-file-element,
	.noresize span[ typeof~='mw:File/Frameless' ] img.mw-file-element,
	span[ typeof~='mw:File' ].noresize img.mw-file-element,
	span[ typeof~='mw:File/Frameless' ].noresize img.mw-file-element {
		max-width: none;
	}
}

That still doesn't solve the issue for flex/grid/table CSS elements however, and I'm not sure we even can. The only solution there is being explicit about min-width or wrapping with noresize I think, which will need to be done by editors on a case by case basis.

The impact of that is and remains hard to assess. Perhaps we can do some metric collection after deploy to see how many more image size to below 5x5px or something ?

An alternate (possibly better) method, is to have the parser emit a 'size class' as an extra attribute, so that the selectors can target images above 150px wide for instance.

PS i updated the test page on beta, to have the table and a flex example defined in a way that they would hit these cases.

@TheDJ @Jdlrobson Reading through this task and trying to understand, is there any reason why someone would use frameless images outside of a table (like the example jon found https://en.wikipedia.org/wiki/Opinion_polling_for_the_2024_United_Kingdom_general_election)? Wouldnt a solution here just be to make it a framed image?

And whats the impact of just leaving frameless images inside table/flex containers as is? Wouldnt adding 'noresize' to tables handle large images, and that could be done by editors on a case by case basis?

From the documentation: "frameless, like thumbnail, respect user preferences for image width, but without border and no right float" - from this definition it does seem like these should have noresize class by default? @TheDJ as someone more experienced with editing do you think that would make sense?

My understanding is that its difficult to make frameless images use noresize by default because there are many diverse use cases where thats not expected. I like @TheDJ 's suggestion of targetting large images. Even if we cant get parser to output a size attribute, I wonder we could just use JS to only apply noresize to large frameless images as a starting solution, and then monitor for community feedback after

(This one isn't ready right now or a major priority for tables)

Web team reviewed this today in quarterly grooming and this task is still valid and should be retained in backlog.