Just to make sure I don't misunderstand, you want to serve 400px thumbnails to all devices, and ask the browser to scale it down for small viewports, right?

Two comments on that:

• On mobile, you probably don't want to serve larger-than-necessary thumbnails; file sizes affect mobile users much more due to lower bandwidth and metered connections. On desktop, is there a use case for this? The smallest screen size you will see for desktop users these days is something like 1024x768; would you scale down the images for a screen of that size?

• There was an RfC that involved client-side resizing: https://www.mediawiki.org/wiki/Requests_for_comment/Standardized_thumbnails_sizes Quoting the architect decision from there: "Please provide evidence that visual quality will not be compromised in any popular UA, whether the source is a photograph, drawing or engraving. Several commenters assert that visual quality will be compromised."

Tempted to change the component to "User preferences" here, if I get things right.

Gergő,

I imagine it would be more like this…

we'd have one size image that gets delivered to uses for in-page content, and it would be the largest that image would appear on a page (not counting mediaviewer), this might be the default display size at the desktop form factor or it could be a larger size for edge to edge display in a tablet breakpoint, lets just say for argument that it is the tablet edge to edge version. So that is the master image size, and as we move through breakpoints, or possibly even during dynamic resizes of the page we use css to scale the image relative to the container element. This way, irrespective of the resizing of the page we always have a high quality image that fits well within the page layout.

This could also be used in conjuction with https://bugzilla.wikimedia.org/show_bug.cgi?id=66819 to detect the pixel density of the device and serve up images which are equal to the pixel density of the device.

For HiDPI devices we could serve an image which is the correct dimensions at the right pixel density or the regular DPI but twice the dimensions, whichever is more performant.

See also

• [Wikitech-l] Initial stab at responsive images for high-density displays

http://lists.wikimedia.org/pipermail/wikitech-l/2012-September/063260.html
(www.gossamer-threads.com/lists/wiki/wikitech/298575)

@helder, thanks, could be useful to refer back to, however I think this is no possible to do in a more native way without relying on JS

Apparently this exists on mobileFrontend already and would be trivial to add to desktop

For HiDPI devices we could serve an image which is the correct dimensions at
the right pixel density or the regular DPI but twice the dimensions,
whichever is more performant.

We already do that (And have for quite a long time at this point). We do it natively on platforms that support it, and use js for those that don't.

There are certain situation (infoboxes) where people want the dimensions of the image to line up with the dimension of the box. We have to be careful to avoid breaking expectations in that case.

Brian, yep that's a good point, we'll want to be smart around things like establishing minimum and maximum widths based on the width of the content container.

Right now the current default skin doesn't responsivly snap to tablet and mobile views at break points but we'll need for this new code to do that. Narrow desktop width for an image may be smaller than a tablet breakpoint that the image goes full width.