comparison

<picture>
  <source media="(min-width: 800px)" srcset="pic-big.jpg 1x, pic-big-hd.jpg 2x">
  <source media="(min-width: 400px)" srcset="pic-med.jpg 1x, pic-med-hd.jpg 2x">
  <img src="small.jpg" alt="…">
</picture>

<img
  src-2="(min-width: 400px) pic-med.jpg 1x, pic-med-hd.jpg 2x"
  src-1="(min-width: 800px) pic-big.jpg 1x, pic-big-hd.jpg 2x"
  src="small.jpg"
  alt="…">

Here’s the very short version of the upcoming post:

Similarly understandable syntaxes, real media queries (!), and based on extensive testing: no double download with a polyfill as well as the option of an alternate polyfill that may trigger a double-download in some environments but has src as a 100% reliable fallback in all environments.

There’s also a new shorthand syntax that will allow us to not reevaluate our sources when the environment changes, for non-art-directed images. If you have the larger version of an image, and resize your window down, you don’t need to make a request for a smaller image with identical content.

We have a lot of new options, and I’m excited to see where it goes.

Forgive me if this is covered elsewhere since I haven't found it, but what is the meaning given by the n? It is ambiguous from this example. I would have taken it to be a precedence indicator of sorts, but the media query more than covers that. Could n just as easily be a descriptive string for the benefit of the developer? <img src-large="..." src-medium="..." ...

n needs to be a number. My understanding is that it would be problematic to sort attributes by source order, hence the numbering. So, src-1, src-2, src-3, etc. The first src-n that matches is what gets used.

As much as I like picture, it seems to me that src-n offers essentially the same features, if not a few more with the viewport-url syntax. The key thing is that src-n allows for media queries that are either min-width or max-width, and it allows for different units such as em. With that, it's pretty straightforward to write media queries that are the same as those used in CSS, so that images can shift at the same breakpoints as the layout does, even when the base font size isn't 16px = 1em.

So if browser developers might actually implement src-n, and thus speed up image downloads through the preloader, thumbs up.

@PizzaBrandon Oh, the n is the selection order.

source elements are first match based on their order in the page—meaning “if your first source matches, all the rest are thrown away even if there’s a better match.”

The n pattern allows us to choose the if … else if … else if order, so we can order them in the markup however we’re most comfortable. “First check src-1, then src-2, then src-3 etc.” Personally, I tend to use min-width for my MQ, and it’s a lot easier for me to read when they’re ordered from smallest to largest the way I do it in my CSS. We couldn’t actually do that with picture, but with src-n we just put the higher numbers first.

(Just had to fix the picture example accordingly, in fact—I still get tripped up by it too, which is a bad sign considering how long I’ve been at this.)

src-n is kind of mimicing a list structure with open-ended attribute names. Seems kind of weird.

Wouldn't a single known attribute be more "standardy" (instead of guessing when src-n stops)?:

<img
alt-src="(min-width: 400px) pic-med.jpg 1x, pic-med-hd.jpg 2x; (min-width: 800px) pic-big.jpg 1x, pic-big-hd.jpg 2x"
src="small.jpg"
alt="…">

Yeah - I know long attribute value - but easily accessible... which is the same as srcset with mq

Suppose each image file has different content because of art direction — for example, the three images in this CSS Tricks article under the heading "Do I care about art direction?". If the change is drastic enough, you might need different alt values depending on which image has loaded.

Have you considering allowing for, er, alternate alt and title values?

@patik, if the change is that drastic, then the developer is doing img wrong.

@patik, to be clear, we don't want to introduce something new that would allow the developer to do what you describe.