Add a pendingSrc or selectedSrc property

[aFarkas]

Currently there is the currentSrc property to get the URL of the current request.

In most use cases where there is also a pending request, the currentSrc isn't that interesting anymore, because it will change soon. It would be great to also have an API to get either the URL of the pending request (i.e.: pendingSrc) or a property that returns either the pending request if it is not null or the current request if the pending request is null (i.e: selectedSrc).

[yoavweiss]

It'd be great to document these use cases, first here and eventually in the use cases document.

[aFarkas]

I'm not so good in producing good use cases, but I would argue, that 90% off all use cases for the current currentSrc implementation could be better solved with a selectedSrc property.

Here is an example using currentSrc from the use case you see, that the author actually would something like selectedSrc or the mix of pendingSrc with currentSrc. To work around he is using a setTimeout.

Although not really a good use case, it also shows that the working of currentSrc isn't so intuitiv and people tend to think/hope it updates sync.

Here is another not so good use case: https://github.com/aFarkas/lazysizes/tree/gh-pages/plugins/bgset
In this script I transfer the selected image candidate from a picture element to the background-image style of another element.

This means, the script does not support progressive image loading, because I have to wait until the image is fully loaded. Although this isn't such a great use case either, it shows that in most cases you want to get the selectedSrc and that you loose something, if you workaround with currentSrc.

[zcorpan]

Do you want to be notified when a new candidate is selected? If so, maybe an event is better than a property. This is why we need use cases. :-)

[aFarkas]

An additional event would make this awesome (in case the loadstart event is fired to early), but it is still about a property that immediately reflect what the browser has selected.

Do you have any use cases for currentSrc? Because as I said, I think most use cases for currentSrc could be simpler solved with selectedSrc.

I think I saw a code example (by yoav), showing this:

//get currentSrc for modern and legacy browsers
var curSrc = img.currentSrc || img.src;

In fact this isn't true. The semantics are slightly different. And you need to write something like this to get some reliable results:

var getSrc = function(img, cb){
   var call = function(){
       img.removeEventListener('load', call);
       img.removeEventListener('error', call);
       cb(img.currentSrc || img.src);
   };
   img.addEventListener('load', call);
   img.addEventListener('error', call);
   if(img.complete){
       call();
   }
};

As I first worked with img.currentSrc I made the exact same mistake and thought it would be similar to mediaElement.currentSrc. (While mediaElement.currentSrc is also updated async, you don't have to wait until something has actually loaded, it is updated as soon as the browser selects/starts to download/test a source).

So I think img.currentSrc isn't so intuitiv. And now (some month later) for the lazySizes extension script mentioned above, I got the following issue: aFarkas/lazysizes#124.

This issue is caused by the fact, that I can't detect, what candidate the browser has chosen, before this candidate is fully available.

[aFarkas]

Just to end this.

In case we would have pendingSrc a reliable code example would look like this:

var curSrc = img.pendingSrc || img.currentSrc || img.src;

And in case we have selectedSrc it would be very easy:

var curSrc = img.selectedSrc || img.src;

[albell]

+1. The use cases would be polyfills and highly customized layout behaviors. For example the author needs to do custom positioning for an overlay over an art-directed image.. currentSrc doesn't provide any information about impending changes. One might think that it updates synchronously but it doesn't. An author might want fine-grained control over what is displayed in the interim period while a newly selected candidate is being loaded. So if an author checks for pendingSrc, and sees that isn't null, then he/she can listen for load. Agreed with @aFarkas that while I like the idea of ultimately exposing all of these internals as events, I don't think this case would necessarily require a new event.

The term selectedSrc sounds odd to me, given that the goal is to distinguish things in time. pendingSrc seems more idiomatic.