I'm TabAtkinsJr,
and I wear many hats.
I work for Google on the Chrome browser as a Web Standards Hacker.
I'm also a member of the CSS Working Group,
and am either a member or contributor to several other working groups in the W3C.
You can contact me here.
Listing of All Posts

People who haven't studied the use-cases gathered by the RespImg folks don't understand what this branch of the syntax does, and decry its complexity. It's really quite easy to defend, though. It's a compact way of expressing all the information you need to handle multi-resolution images of variable size. The image might vary based on the viewport width (for example, it might fill 100% of the viewport), or it might vary based on your layout breakpoints, as you deliver differently styled pages to small and large screens.

The spec itself does a good job at defending its usefulness in the simplest case, when your image is a percentage of the viewport. That looks something like this:

<img src-1="100%; 400.jpg 400, 800.jpg 800, 1600.jpg 1600">

This isn't too hard to read - the first part, before the semicolon, says that the image's width will be 100% of the viewport's width. The second part is just a list of images, but rather than giving each a density descriptor, it just provides their width in image pixels.

The browser uses these two pieces of information to figure out the effective density of each source image, and chooses which to download based on that. For example, on an iPhone with a 320px viewport, the first source is effectively 1.25x, while the second is 2.5x. On the other hand, on a 1000px-wide laptop screen, the second source is .8x and the third is 1.6x.

Doing the same thing with srcset is possible, but it's verbose, especially if you want to future-proof things well to cover densities from .5x (potentially useful for downloading things quickly over a slow mobile connection) up to 3x (some devices on the market now are hitting this point now) and higher. The spec has an example of this.

More Complex Examples

What the spec doesn't have, because I didn't want to spend the time writing it, is an example of just how verbose srcset gets when you have a more complex example. Here's a pretty basic one:

Here, the first part is a bit more complex. It says that your layout has two breakpoints, at 640px and 960px, where your layout changes. In the smallest layout, this image will be presented at 100% of the viewport width, in the next it'll be 50% (a two-column design, perhaps), and in the largest it'll be 33% (a three-column design).

Reading this requires a little bit of knowledge, but nothing crazy. You need to know how the syntax works, but it's easy, and once you do, it's really simple to see what's going on. Importantly, it's also really easy to maintain - if your breakpoints change, or you add more, the necessary modifications to this syntax are small and obvious.

The breakpoints are completely invisible now. (If you look closely, you'll notice the odd width descriptors of 639w and 959w, which is a hint that something different's going on there, but that's an artifact of how they're supposed to match up with the MQs. If they'd been done as 640w and 960w, you wouldn't be able to see the breakpoints at all except by examining the relationship between each segment's max width and the densities of the images.)

You have to do non-trivial math to figure out how many divisions to put in each breakpoint (they're split into 3, 2, and 4 sections each).

You have to do non-trivial math to figure out the densities at each division - find the average of the min and max viewport widths for the section, then divide the image widths by that value.

The knowledge that the image is 100%, 50%, or 33% of the viewport is completely hidden, and can only be recovered by reversing the density back to a width and comparing it to the viewport width limit.

It's much less future-proof. This only covers approximately the 1x to 2x range. Smaller and larger densities aren't addressed at all, and doing so makes the markup even more terrible.

It's so much less maintainable. Changing any segment limit involves fixing 4-5 NNNw numbers, and adjusting 4-5 densities. changing your layout to use a different image width involves recalculating 10-20 densities, since those are derived quantities.

Literally every single aspect of this markup is markedly worse than the src-n alternative. The pain is so great that I don't think it's possible to reasonably argue that forcing authors to do this is better than forcing authors to learn a new microsyntax for src-n.

One could try to argue that this use-case isn't valuable enough to address, but I think the use-case gathering by RespImg folks, especially John Mellor for this particular topic, puts the lie to that. This kind of thing is a reasonable thing for authors to do, and which will be done a decent fraction of the time when responsive images are used at all.

a couple of extra resolutions, and an SVG path would have been probably smaller. This way to deal with resolutions for raster images is simply insane, I wish all browsers where already supporting SVG images, SVG icons for the home screen, SVG everything so the problem, at least for images that are not pictures, would be solved once for all.

I guess the only issue with these approaches is that information about the layout of your page is leaking through into the markup -- so if one were to completely redesign a website that was using this syntax, it would be necessary to update the markup to match. That being said, of course, the line between presentation and markup is distinctly blurry, particularly for the art direction use case...

I do like putting the onus on deciding which image to load onto the browser (using src-n) -- as you've suggested, this means that browsers can elect to load (what they assume to be) a smaller image in certain situations. I think that this is probably one of the big wins of the src-n approach, to be honest.

The way I explained the complex part of the src-n syntax during the Fronteers conf was using a "spray and pray" analogy: You "spray" a whole bunch of image sources for a particular break-point, and "pray" that the browser picks the right one :)

I guess the only issue with these approaches is that information about the layout of your page is leaking through into the markup

Yeah, that's an unfortunate but necessary aspect of this. We're extremely restricted in what we can do here, since we have to be friendly to the preload scanner, which knows very little and can't depend on any linked documents.

Re #8: CSS for individual images is difficult but I agree it shouldn't be in the markup either. Something like the favicon format shows how this should be done: in the image itself. Add filters to the http servers and browsers always get what they want. Simply asking for the size doesn't cut it if you want to reduce bandwidth.

Could the size-viewport-list be specified as optional. In this case the browser might delay loading until the needed image pixel size were known, or speculatively load the smallest and reload later if necessary etc.

Could the intrinsic size be well defined, irrespective of the size-viewport-list.

All content on this blog, unless otherwise noted or obviously owned by someone else, is licensed under the
CC0 license
.
This means you can use, repost, translate, chop up, remix, or do anything else you want with the contents of this blog,
without asking me.
(Seriously, don't ask me. It's annoying. That's why I use this license.)