I've seen this done with a php extension on the file. Basically, you don't link to images directly, it goes through a processor. So when you click "View Image" (or whatever) it doesn't link to "file.jpg" it links to "file.php?data=info" which then uses GD to scale the image. This will cache a properly sized image both on the server and in your browser cache.
I suspect with a little mime jockeying (or some other technique) you could make it so you can call file.jpg and have it go through your GD scripts.
ADDED: I was curious about this, so I looked. Here is the answer to "how". So now your php can get EXACT numbers that adapt to values relative to it's container.
Currently we're making CSS with several different cut-off-points and then dynamically scaling things within that. What if you could have one cut-off point to determine "full screen - two columns" and "small screen - stack into a single column and adapt interface". And THEN you could stack that page with specific dimensions? And your images could be a specific width rather than a percentage of an arbitrary number. And imagine if those images were cached and delivered at their proper size rather than being scaled as a percentage that probably doesn't fit into the Rule of 8s?
True, this site probably isn't doing ALL of that... but the Rule of 8's bit is probably what they are dealing with right now. (I'm not sure what this rule is actually called - I just call it that). If you aren't familiar with the Rule of 8 - basically, in web and graphic design for the web, every number you use and every graphic resolution you make should be divisible by 8. All screen widths do this. 800x600, 1024x768, etc. If I create a graphic and need to scale it, if it starts at a number that is divisible by 8, then there is very little loss. 50% of an 800x600 graphic is 400x300 - another number that is divisible by 8. This means that every line and row of pixels was used when figuring out how to scale the graphic. If I started with something that was 807x298, and do the same division, there are certain rows and columns that are just going to end up being discarded or unevenly represented in the scale model. This makes the image look blurry - whether you are scaling it with CSS or in phothoshop before you upload it, or whatever.
You're 50x50 example doesn't fit into the rule of 8, but it could fall into the rule of 2 - which can be just as good if you are consistent in your divisors - 50% (and 25%), 20%, 10%, etc.
Now, let's look at responsive design...
When we make our CSS sheets we don't account for every screen size. We usually pick 3 or 4 and deal with those. The thing is, none of the numbers we pick are "real" numbers. They are "if it's less than" type numbers we'll do things like @media screen (max-width:699px;) and @media screen (max-width:299px;) or whatever. At that point we still don't know the exact size of the screen. If it's hitting the 699 screen, it could be 640. It could be 480. It could also be 600, 540, or 360.
So, here's the thing... if you REALLY want to "not be lazy" and upload an appropriately scaled image and have a style that will format it, you need to make one for EVERY screen width on this page. And you also need a CSS declaration, too. I've got a big shiny quarter, a nickle, and three pennies in my pocket that I would wager to say no one here is doing that.
Maybe (I'd bet "probably") the site in question is declaring many more than the typical 3 in their CSS, and then dynamically generating an image to scale with the least amount of loss. They MIGHT even be doing what I described above and dynamically generating the CSS to match ANY resolution, too, but even if they aren't and they are just taking into consideration desktop monitor, tablet horizontal, tablet vertical, phone horizontal, phone vertical - that's 5 different sizes, with 5 more thumbnail versions to make - for every graphic you're going to put in there.
Sorry to disagree, but ultimately, this isn't lazy. It's where responsive design is going next. You've stumbled on the future - embrace it.
Edited by Grumpus, Today, 05:45 AM.