Add srcset support

[hatsumatsu]

Using the recommended markup (http://www.filamentgroup.com/lab/to-picturefill.html) for <img> with srcset while using picturefill seems to break imagesLoaded on browsers with native support for srcset. Let's say I have an image like

<img srcset="image-400.jpg 400w,
             image-800.jpg 800w,
             image-1600.jpg 1600w"
>

We don't use src here to avoid loading two images.
Then we use use picturefill for browsers that don't support srcset natively.

In both browsers with and without native support (thanks to picturefill) the right image is loaded, but imagesLoaded reports the image broken on browsers with native support (resulting in not being able to fade the image in smoothly when loaded)

Check out this reduced test case on latest Firefox (v.35: working) and Chrome (v.40: broken):
http://codepen.io/superstructure-net/pen/EaWvZv/

Any ideas? Thx!

[hatsumatsu]

Really no one's having trouble with responsive images + picturefill + imagesLoaded?
Looking into imagesLoaded's code I wonder if it's ready for responsive images at all.

Since in
https://github.com/desandro/imagesloaded/blob/master/imagesloaded.js#L293
the script checks for the image's src it will only detect the loading progress of the fallback image (if specified), right? That would explain why it is failing when no src / fallback image is specified. On browsers without native srcset support (Firefox v35) picturefill manually sets the src before imagesLoaded kicks in, that's why it's working in these browsers.

In the case described (srcset defined but no src) we could wait for the image's currentSrc attribute to be set (by picturefill) if srcset is defined and then continue as usual.

[spoeken]

+1

[pawelgur]

+1

[theamnesic]

+1 !
#166 talk about currentSrc too.

[hatsumatsu]

There is a related topic in the picturefill repo: scottjehl/picturefill#401
In this thread @aFarkas posted a replacement for ìmagesLoaded` that looks promising:

https://gist.github.com/aFarkas/15de1cea3acd6602a71e

[hatsumatsu]

Might be a little off-topic, but I ended up approaching the issue from a different perspective and writing jquery.imagePlaceholder. In short, instead of waiting for the images to be loaded I add empty <canvas> elements with the same width and height attributes as the original images to the container elements. By doing so scripts like masonry can get the container's dimensions immediately for calculating the layout... Check out the demo, feedback appreciated.

[aFarkas]

While this issue should be solved. I think in most cases the problems that are solved by imagesloaded should be solved in a different way.

In general imagesLoaded is mostly used to read and write layout after all images inside a specific widget (slider, masonry or what ever) are loaded.

But this has some problems:

1. There is currently a draft introducing a new attribute called lazyload for different elements including images (and lazyloading via JS is a pretty common technique)
2. responsive images in form of art directed images using the picture element, do never have a final complete state
3. Waiting until everything is loaded until doing layout is pretty bad for perceived performance, especially if we have a slow connection

So how should we deal with this in a future proof way?

1. Developers using a slider/masonry
   Devs who are using such a script, should make sure, that the dimension of images are already defined via content attributes or CSS. In case of responsive images devs can use the CSS intrinsic ratio pattern to provide the dimensions. This does not only solve the problem. It also minimizes reflows.
2. Developers developing a slider/masonry
   Often developers who create such a script, want to be able to give something robust and convenient, that also works, if the markup/CSS isn't done perfect. Therefore it is no option to rely, that the image dimensions are calculable via CSS. But instead of waiting for all images to be loaded to react on, there is a simple pattern to progressively update the layout after an image has loaded.

An example for masonry used as a plugin would look something like this:

$('.masonry-container').each(function(){
    var $masonry = $(this);
    var update = function(){
        $masonry.masonry();
    };
    update();
    this.addEventListener('load', update, true);
});

Most such scripts already bind global events to window.resize to progressively update layout on resize, but I really don't understand, why they don't already bind events to get informed if a children image has changed (and instead wait for all images to be loaded).

[hatsumatsu]

@aFarkas: I agree on that, especially that it's bad UX to wait (without visual feedback) for all images in a given layout to be loaded until doing the layout math. But regarding your post I was wondering:

make sure, that the dimension of images are already defined via content attributes or CSS

How to programmatically achieve this in case of art directed responsive images using <picture> where the aspect ratio can be different on every <source>? Afaik there are no dimension attributes on <source> elements neither is there a fallback source with an intrinsic aspect ratio as there is in <img srcset="" src="" sizes="">. I can only think of putting the <source>'s dimensions in data-attributes, using JS to figure out what source is chosen by the browser, then calculating the image's actual dimensions in the layout and finally applying these via inline styles.

this.addEventListener('load', update, true);

I must admit that I've never seen this pattern using the load event on generic DOM elements to check for child images to be loaded? And wasn' t imagesLoaded initial goal to overcome the browser implementation problems of the load event applied to images?

Despite most demos imagesLoaded can of course be used differently than waiting for all images in a given layout to be loaded. F.e. wait for each image separately to be loaded and pass these elements one by one to layout algorithms like masonry.

btw, your gist is doing a pretty good job for this use case :)

[aFarkas]

How to programmatically achieve this in case of art directed responsive images using <picture> where the aspect ratio can be different on every <source>?

By extending the normal intrinsic ratio pattern with media queries:

<style>
.ratio-container {
    position: relative;
}
.ratio-container:after {
    content: '';
    display: block;
    height: 0;
    width: 100%;
    content: "";
}
.ratio-container > * {
    position: absolute;
    top: 0;
    left: 0;
    width: 100%;
    height: 100%;
    display: block;
}

.ratio-container:after {
    /* 600 / 14 */
    padding-bottom: 42.857%;
}

@media (max-width: 1050px) {
    .ratio-container:after {
        /* 600 / 9 */
        padding-bottom: 66.666%;
    }
}

@media (max-width: 500px) {
    .ratio-container:after {
        /* 40000 / 525 */
        padding-bottom: 76.19%;
    }
}
</style>

<picture class="intrinsic-ratio">
    <!--[if IE 9]><video style="display: none;"><![endif]-->
    <source
            srcset="http://placehold.it/525x400"
            media="(max-width: 500px)" />
    <source
            srcset="http://placehold.it/900x600/e8117f/fff"
            media="(max-width: 1050px)" />
    <source
        srcset="http://placehold.it/1400x600/117fe8/fff" />
    <!--[if IE 9]></video><![endif]-->
    <img
        src="data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw=="
        alt="image with artdirection" />
</picture>

Afaik there are no dimension attributes on elements neither is there a fallback source with an intrinsic aspect ratio as there is in <img srcset="" src="" sizes="">.

Sad story, this still needs to be standardized, but is put on hold until a CSS specification for aspect ratio is ready.

I can only think of putting the <source>'s dimensions in data-attributes, using JS to figure out what source is chosen by the browser, then calculating the image's actual dimensions in the layout and finally applying these via inline styles.

Yep, exactly. here is the script.

I must admit that I've never seen this pattern using the load event on generic DOM elements to check for child images to be loaded?

I would assume, because the combination of event capturing and event delegation isn't well known (and isn't even possible with jQuery/IE8-).

And wasn' t imagesLoaded initial goal to overcome the browser implementation problems of the load event applied to images?

The load event in browsers does work just fine for our use case. The main problem is to detect wheter an image was already loaded, in cache or failed before the script is run (This problem is worked around by imagesLoaded. imagesLoaded is more about complete than load). The "load-update pattern" above doesn't need to know, whether an image was already loaded. It calculates layout immediately (without knowledge) and simply updates layout as soon as the load event is fired.

Also note, that most bugs are already fixed and the most annoying one was just fixed.

In the very near future you will be able to do this:

var img = document.querySelector('img');
var onComplete = function(){
    //do it
};
if(img.complete){
    onComplete();
}
img.addEventListener('load', onComplete);
img.addEventListener('error', onComplete);

[hatsumatsu]

Thanks for clarifying, great work! Looking forward to the day these things are not only spec'd but have broader browser support, too...

PS: I think there is a typo in your last code snippet, shouldn't onLoadeded(); be onComplete()?

[aFarkas]

@hatsumatsu
Thx, fixed.

[tiagogon]

+1.. imagesloaded also doesn't work here with "srcset"

[tiagogon]

oh, just used a ratio-container, and fixed my issues with masonry ;) thank you @aFarkas ! your posts here helped me a lot! <3