Just tried it and it looks like you can remove height/width: auto and things work out? How are we setting height/width? Are we resizing the images proportionately when we download them? As long as we have static dimensions within our max height/width we shouldn’t need anything else.
Yes, CSS-defined background-image is a little nicer in this regard because you can set the container to fixed dimensions and then say
background-size: contain; (will fit entire image to container proportionately, which may leave some white space on 2 sides).
Ultimately though, you’re not really doing much different here than if we put the images a placeholder container with static height/width. For a tall/narrow image you’d end up with whitespace on the sides of the image. We’d be losing the current functionality of reflowing the text around the image without leaving extra whitespace.
Right, accommodating wildly different aspect ratios is tough. To stay proportionate we can only define width OR height, but one property has to be set to auto. We let one dimension hit the max-width/height, and auto-define the other. Without applying auto to the other dimension, we run into proportion issues (for example, we don’t seem to specify auto on flickr embeds? see the stretched dog here)
So if I understand what you’re saying: the problem with CSS is that if you give an image a width of 120px and set a max-height of 200px — once you toss a 120px by 500px image into that box, it’ll be squished vertically.
If you know the aspect ratio of the original image you could do the math using calc() in css? You’d need some logic to determine if you should be defining or scaling height/width? You’d also be essentially supplying all the numbers to specify a percentage anyway? Maybe I’m overthinking it.