I'm confused as to why you would remove src?

The example above is bad (and yes, I know Tab has it in the spec) because it assumes you serve the big image to legacy browsers. Legacy browsers should only get either small or a well compressed medium.

A small src image might be a more appropriate default for RWD/mobile-first thinking, but it'd work either way right? picture[src] isn't a legacy concern like img[src] is.

+1 @scottjehl.

I really like this proposal, FWIW. Feels like a great compromise, and avoids the doubled-up request liability of srcN.

@marcoscaceres Someone had done some research on this a while back, but the basic idea is that in some browsers, removing the src attr from an img element resulted in either browser creating a 404 http request I believe for the img, or other odd issues.

@scottjehl Yea, small image would be the way to go. I grabbed the srcN markup from Tabs spec, but I would personally start with a mobile image for my default.

@beep - Thanks, yeah the main thing here is preventing extra http requests and other issues with pairing srcN with a img element.

i like it overall. much cleaner than current polyfill. what about something like:

// Default use

<picture src="pic-small.jpg"
         sources="(min-width: 400px) pic-medium.jpg,
                    (min-width: 1000px) pic-large.jpg"
         alt="Obama talking to a soldier in hospital scrubs.">

// No JS fallback/Markup used to build polyfill

<picture src="pic-small.jpg"
         sources="(min-width: 400px) pic-medium.jpg,
                    (min-width: 1000px) pic-large.jpg"
         alt="Obama talking to a soldier in hospital scrubs.">
<noscript><img src="pic-small.jpg" alt="Obama talking to a soldier in hospital scrubs."></noscript>

since we will be using javascript anyway to build the thing, keeping one attribute only is much cleaner/easier to parse (split ,)

@zigotica, I like the sources attribute idea. I'm not familiar with the browser implementation side to say if that would be better or not, but from a developer side, I like it.

@marcoscaceres I guess you wouldn't need to remove the src if srcN is used on a new element like picture/pic. I've also reworked the example so it's mobile-first. I'm curious to see Tab's and Hixie's feedback on this.

@zigotica: Splitting on commas would break data-URIs (and splitting on Nth-spaces will lead to authoring chaos), so I get the appeal of stand-alone srcN attributes or source elements.

Also worth noting that the srcN pattern introduces an author-controlled selection order (“First match, starting with src1 and working up”), rather than just source order.

@Wilto hmmm, i see :(
still, much cleaner and less verbose than current picturefill

…current picturefill which i love, just for the record @scottjehl :)

to re-iterate a point i made on twitter: since there's already a syntax we know/love as picture, maybe this could use pic or something else for the time-being, just so we have an easy way of distinguishing it in discussion from the existing picture syntax. (and also possibly avoiding some of the picture animosity that's out there.)

@nwtn I've switched the markup to use pic instead of picture to make it more clear when talking about responsive image solutions.

@bjankord @nwtn <imagen> ?? (bonus points for being the spanish word for image)

@bjankord Awesome. I'm really digging this.

One of my reservations with src-N was the ability to do file type switching, but Tab has tweeted about that. I'm not familiar enough with image-set to know if the same idea would work here. Thoughts?

Yes, it would work fine. You'd just do something like src-1="foo.webp 1x type('image/webp'), ...". The source selection algorithm would delete images with unknown types, and reject the whole attribute (moving on to the next) if nothing was known at all.

@nwtn Yes, I hadn't seen much on file type negotiation that was in picture with scrN yet, but I think it is very important to a responsive image markup solution. Curious to see what Tab comes up with.

@Wilto what about splitting on semicolons? ie sources="(min-width: 400px) pic-medium.jpg;(min-width: 1000px) pic-large.jpg;(…);foo.webp 1x type('image/webp')" kind of thinggie. Isn't src-N still too verbose?

This still has every MQ repeated for every image which isn't very DRY. Presumably there's no reason for this not working with MQ variables though?
http://lists.w3.org/Archives/Public/public-respimg/2013Sep/0036.html

There has been much (or not enough, depending on who you talk to) discussion about using CMSes as the primary way to create content. So in that respect, the MQ being repeated on every image would quite easily be able to be a variable... not the perfect solution, but one that would work for the majority of cases.