I love the debate and the enthusiasm being shown to find an answer to the responsive images conundrum. People are trying to get shit done and I like that attitude because we need a solution to this problem. But the question is whether we want to introduce something in HTML that we will probably regret in the future.
Current Situation
To be clear, there currently are a couple of different proposals popping up at WHATWG and the W3C, of which the two most popular syntaxes are:
<img src="face-600-200@1.jpg" alt="" set="face-600-200@1.jpg 600w 200h 1x, face-600-200@2.jpg 600w 200h 2x, face-icon.png 200w 200h">
and
<picture alt="">
<source src="mobile.jpg" />
<source src="large.jpg" media="min-width: 600px" />
<source src="large_1.5x-res.jpg" media="min-width: 600px, min-device-pixel-ratio: 1.5" />
<img src="mobile.jpg" />
</picture>
Two Problems, not One
The way I see it, having read through the proposals and a lot of (but not all) comments, there are two very different problems being mixed up: 1) available bandwidth and 2) viewport size. Both problems should be tackled with different solutions.
Problem One: Bandwidth
In my opinion, the bandwidth problem is not something that we should try to solve in a markup language. It is something that should be handled by the client/image format itself. Progressive JPG files actually already kind of solve that problem in a very good manner—although we could benefit from better implementation. A browser (or whatever client you use to fetch data) is much more fit to decide whether it should download the high-res (complete) version of an image, or stop downloading the image after n passes/amount of data has been transmitted. That has absolutely nothing to do with viewport size. And seriously, who wants to save low-, medium- and high-res versions of every picture they have on their server? Imagine what a clusterfuck of image files that becomes when you also cater to viewport size . . .
Problem Two: Viewport Size
Concerning the viewport size, metadata is much more fit to tackle the problem. It could, for instance, make a lot of sense to use a different crop of the same image on a small screen and use the full crop on a big screen. But again, I am not sure whether that kind of descriptive info really belongs in HTML.
Essentially, what you’d want is a separate meta-file (xml, maybe?) that describes the different crop points of the image, much like SVG describes beziers–but unlike SVG in that it doesn’t describe itself. That way, image editing software can be used to define the crop points and generate and maintain that file, separate from the HTML document. And also that way, you can do some awesome backwards-compatible stuff like:
Of course, we’d have to think a bit harder about the syntax, possible use cases and things like optimization. But I just really, strongly believe that this does not belong in HTML itself.
—
This is partly taken from a discussion at a W3 Community Group about responsive images
