Miscalculated width of slides track on variableWidth with progressive lazy load

Hi Ken, First of all - great plugin, fantastic work, respect!

However, with the new feature “variableWidth” combined with progressive lazy load and centerMode, I encountered problems when having higher amount of image slides in the slick (ca 100+).

The width of “slick-track” element on first few calls to setDimensions seems to be miscalculated - track is slightly shorter than it should be, as the images while initializing do not give correct slide width to the slick.

The effect of this issue is fairly bad: slide-track expands for two rows (as the fully loaded images can not fit within miscalculated track width).

After while (when all progressive images are fully initialized), all is getting back OK, f.e. after first slide change all gets finally calculated correctly and slick is looking fine.

I did not have a time to dive deeper in your code, so i just created kind a dirty hack to fix it (see bellow), but I think this issue shall be addressed and get resolved more elegant way.

The merit of my hack is simple:

1. it simply checks the slick-track width on every call to setDimensions, and compares previously calculated width with the newly calculated. if it differs (width changes as the lazy loading images still continue initializing), it sets the track width manually for INSANE value, e.g. 500000 (to surely accommodate all slides).

2. Once slick-track width stabilizes (previously calculated width equals to new), all returns to normal and manually setting the insane width is bypassed. Track has correct width, and looks good.

As the process is quite quick, the hack does not have any bad influence on initial display, the slick simply starts “fixed” as it would normally, but it is really dirty hack. 😉

THE HACK

First, I created new var for storing the slick-track width (at line ca 144): _.lastTrackWidth = 0;

Than, I modified the setDimensions method, inside >variableWidth === true< condition (line ca 1335):

    } else if (_.options.variableWidth === true) {
        var trackWidth = 0;

        // *** edit
        // *** HACK for miscalculated track width while progressive lazyLoad (wrong slide widths)
        if (_.options.lazyLoad == "progressive" && _.$slideTrack.width() !== _.lastTrackWidth ) {
            trackWidth = 500000;
        }
        // *** END edit

        _.slideWidth = Math.ceil(_.listWidth / _.options.slidesToShow);
        _.$slideTrack.children('.slick-slide').each(function(idx){
            trackWidth += Math.ceil($(this).outerWidth(true));
        });
        _.$slideTrack.width(Math.ceil(trackWidth) + 1);

        // *** edit
        // *** HACK for miscalculated track width while progressive lazyLoad (wrong slide widths)
        _.lastTrackWidth = Math.ceil(trackWidth) + 1;
        // *** END edit

    } else {

Please, I am sure you will have better idea, and I hope in a mean time the above may help somebody to resolve this issue in a dirty way, before fixed in source.

Thanks

[larzilla]

I was having this same issue. My fix was similar to @alvinpascoe. One of the parent elements was set to display:table. Once I changed this parent to display:block, the issue was solved.

[virtual]

Thanks @chrisdatlas, adding the min-width of 100% to .slick-track worked for me; now they aren’t stacking small images anymore