notes.md

Creating a new element named picture or pic that mirrors the img element would allow for an easier responsive image element to polyfill.

When polyfilling srcN paired with the image element, legacy browsers which don't support srcN would download the image from the src attr and the matching srcN attr. This would result in dual downloads in legacy browser which need the srcN polyfill. These "legacy browsers" are every browser today.

A few ways around this would be to leave the img src attr empty. Or remove it all togher.

From Riloadr docs, Túbal Martín has some concerning notes about leaving the src attr empty on img elements.

Warning!: Do not set an empty string for the value of src src="". Some browsers react to this by assuming the empty string means src="/", and consequently the browser re-requests the current >HTML page and tries to stuff it into the element. This is bad news for performance.

So leaving the src attr empty is a no go. I'm not 100% sure if there are issues with removing the src attribute altogher from the img element. I feel like some browsers will add the attribute back which would leave us with an empty src attribute.

I've put a demo together to do some testing when the img src is empty/removed altogether which can be found here.

If you could use scrN on a element besides img, it would resolve some concerns with polyfilling a srcN solution.

Update 0.1.0

It looks like in IE, IE11 - IE7, no image icons show up if you leave the src attr empty on an image or leave it off altogher. This may be a mute point as the src attribute would be populated or added back with the polyfill. Users without JS will see all those lovely icons in IE though. IE users and users without JS, two groups people really care about.

I've reached out to Tubal to see if he can give some more info about what browsers have issues with empty src attributes on the img element. I've also updated the markup to use pic instead of picture per request.

Update 0.1.1

Additional resources:

http://www.nczonline.net/blog/2009/11/30/empty-image-src-can-destroy-your-site/

http://www.nczonline.net/blog/2010/07/13/empty-string-urls-browser-update/

https://github.com/Wilto/srcn-polyfills

https://github.com/jonathantneal/respimg

scottjehl/Device-Bugs#3 Read note about "or the image src is invalid"

Creating a new element would allows us to leave the oddities of images with empty or no src attribute behind.

picture.html

// Default use

<pic src-1="(min-width: 1150px) pic-large.jpg"
         src-2="(min-width: 500px) pic-medium.jpg"
         src="pic-small.jpg"
         alt="Obama talking to a soldier in hospital scrubs.">

// No JS fallback/Markup used to build polyfill

<pic src-1="(min-width: 1150px) pic-large.jpg"
         src-2="(min-width: 500px) pic-medium.jpg"
         src="pic-small.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>

@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.