The Responsive Image Solution Does Not Belong in HTML

Written on 2012-05-15 • conversation (4)

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

Conversation is closed

Conversations close automatically after six weeks. Feel free to contact me directly if you have feedback on this article.

I absolutely agree, if only because redesigns or rethinking of the responsive model should not affect the html at all. If you introduce another breakpoint, you shouldn’t be going back to your html to add a list of extra images for that new breakpoint.

The XML idea is nice, but since responsive is all (or mostly) about visualization I believe the solution belongs in the css.

— Niels Matthijs · Tue 15 May 2012 · #

1) multiple versions/derivatives of each image: the CMS should do this for you.
Breakpoints may change as the responsive design changed: same answer.
It is an absolute nightmare/no-go to maintain or even just write this HTML manually.

2) crop points depending on the breakpoint; the CMS can also do this out automatically to a large degree, unless you want full control over the crop points.
The solution you propose has incredibly terrible performance implications, especially on mobile. I understand your reasoning, but that’s absolutely in feasible!

Both are solved in the upcoming Drupal 8 by using Image Styles, where you have a different image style depending on the breakpoint. Each image style consists of a series of image operations, e.g. scale, crop, saturate, etc.

— Wim Leers · Sun 4 Nov 2012 · #

@Wim I am really curious about the performance implications, since that is not something I can properly evaluate at this point—mostly due to lack of deep knowledge. Where do you see potential problems?

The reason why I propose a solution that goes beyond just websites is mostly because a browser is not the only thing that will benefit from “responsive images”. Serving the right image to a native application can be an equally daunting task, which is the reason why I think the solution has to be conceived with the broader context of websites/web apps, hybrid apps and native apps in mind.

I am very eager to see how the Drupal 8 solution will pan out in practice, since it will have an impact on such a large scale!

— Xavier · Sun 4 Nov 2012 · #

JPEG2000 everywhere. That is all; users zooming into your favicon most of the time, ad scripts affirming that refresh is frequent and the clickthrough impossibly far away to disclaim. Most images are raster viewports on SVG graphics, but an SVG viewport on a raster image is also possible; surely we should be able to specify the sort of jerky loading and antialiasing needed to convey various hopes without laying too hard into content. And can noone use WebP but Google because of some ICC profile dustup?

— Steve Nordquist · Wed 6 Mar 2013 · #