tkahn
For big galleries - making the scroller work immediately after document.ready
I have a rather big gallery on this site http://ateliermoscow.com/en/stars/, and it's a pain to see the scroller not working until all images are loaded (which may take up to several minutes). I managed to overcome this by forcing the hotspots showing immediately after the page has loaded (with CSS:
div.scrollingHotSpotLeft, div.scrollingHotSpotRight {display:block !important};
and JS:
$('.scrollingHotSpotLeft').addClass('scrollingHotSpotLeftVisible');
$('.scrollingHotSpotRight').addClass('scrollingHotSpotRightVisible');
) and by commenting out lines 1026-1027 in your script:
el.data("scrollWrapper").scrollLeft(el.data("startingPosition"));
el.data("scrollXPos", el.data("startingPosition"));
I guess it's also obligatory to have widths of images declared, so the script could calculate the total width of the scrollable area right from the start. I may not get all the picture, but the gallery now works fine right after first few images have loaded. If you think the idea is good, please consider implementing it in your script.
You could always put a preloader on you're site: ImageReady is a good one to use.
Alternatively you could delay the loading of your images until after the document is ready, something like this (I found on StackOverflow):
< img src="#" delayedsrc="http://mydomain.com/myimage.png"/ > Then, add a javascript line when your page loads that does something like this (untested, but you get the idea):
$('img').each(function(){ $(this).attr('src', $(this).attr('delayedsrc')); });
Well, preloader solves the problem only in cosmetical sense. As I said, the loading of all images sometimes takes up to several minutes, and as we deal with not some compiled big piece of content but hundreds of discrete smaller ones, it may be not good to force visitors to sit and watch the preloader moving for 3 minutes instead of giving him the content that already have loaded right away. Also I tried the approach with a fake attribute but finally gave it up because it's not semantic, the pictures won't be consumed by search engines etc.
Hi!
The problem has been that many users cannot or do not specify the dimensions of the images they put inside the scroller. This has forced me to write the plugin so it will work eventhough no dimensions have been specified. And the only way to calculate the total width of all the (unspecified) images has beed to load them all.
So this is not really a bug but rather a design decision made after having recieved a lot of feedback from users that couldn't or wouldn't specify the image dimensions. The very first version of SmoothDivScroll (or rather its ancestor) relied on widths being specified inline or in the CSS.
Nevertheless I still agree that this can be a problem if you are waiting for lots of images to load.
/Thomas
Yes, I agree with tkahn. But What about responsive designs? In my case, images inside the scroller are height:100% and the width is auto. This is the only way to have a vertical responsive layout. In that case, I need to calculate the whole images width first in js and the pass it to the ul with images.
It is true that adding images a bit big the scroller has some performance issues.
Do you know why does happen this?
I think that adapting the plugin to work with responsive layouts will be a challenge, but an important one. The reason why it's a challenge is that SmoothDivScroll does a lot of calculating - the position of different elements and the position of the mouse pointer inside the scrolling hot spots, width's and height's of elements and so on. In a responsive layout you can still get the numbers but things tend to move around and change much more than on a traditional web page with a more static layout.
/Thomas