Can you put 2 slideshows on the same page

[molendijk]

Mcolton, here's a demo of what I said in post#8 about the multiple-iframe approach: one slideshow-script only but multiple slideshows.

[jscheuer1]

But the real problem is that, when you have made everything transparent, then image-transition is not fluid anymore when going from a larger image to a smaller one.

I thought I acknowledged that. In any case, I agree. To overcome it, I see two possibilities - 1.) Set the background image of the gallerylayers to whatever it is behind the slideshow so it only looks like they're transparent. That usually also requires that the bg image for the gallerylayers be positioned to line up with the one behind the show (this can sometimes be done in style alone, but if the slideshow is centered or can appear in at least slightly different positions on the page due to whatever circumstances, it must be scripted*). 2.) Fade out the departing image while fading in the arriving one (requires some modification to the slideshow, or a different slideshow). However, this (#2) often isn't all that smooth either because two animations must be handled by the browser/computer at once. Many browsers and computers can handle this now though. When the script was first written, this was far from the case, most could not.

*I've done this at least several times for folks, but it's a bit tricky and usually page specific. If I remember correctly I utilized both the optional oninit and sometimes the optional onslide functions available for this script, and sometimes had to tie in window on resize if that would have an effect on the alignment. Relative simple maths can accomplish this, but determining the exact equations and constant values they required was a bit tricky for me, and, as I say, page dependent.

[molendijk]

I thought I acknowledged that.

Sorry John, I didn't mean to be rude.

I see two possibilities - 1.) Set the background image of the gallerylayers to whatever it is behind the slideshow so it only looks like they're transparent. That usually also requires that the bg image for the gallerylayers be positioned to line up with the one behind the show (this can sometimes be done in style alone, but if the slideshow is centered or can appear in at least slightly different positions on the page due to whatever circumstances, it must be scripted*). 2.) Fade out the departing image while fading in the arriving one.

I'm attracted to solution #2. That's also what's done by the script used in my post#11-demo, but the DD-script can do certain things that my demo-script can't do.

[jscheuer1]

Sorry John, I didn't mean to be rude.

I'm attracted to solution #2. That's also what's done by the script used in my post#11-demo, but the DD-script can do so many things that my demo-script can't do.

It's been awhile, so I cannot be certain if this can be done with the current version of Ufade (generally almost anything can be done with any script, just a matter of how much code you want to write). But, at one time there were several attempts made at editing the script to make it act this way (Fade out the departing image while fading in the arriving one). If memory serves, at least a few of them worked well for those browsers/computers that could handle the amount of clock ticks, whatever the two concurrent animations require. Another alternative I just recalled was to fade out one image and then fade in the other such that only the background shows for a very brief moment. Not as nice in certain ways, but doesn't challenge slower browsers/computers any more than the current script does.

[molendijk]

But, at one time there were several attempts made at editing the script to make it act this way (Fade out the departing image while fading in the arriving one). If memory serves, at least a few of them worked well for those browsers/computers that could handle the amount of clock ticks, whatever the two concurrent animations require.

I tested my demo on a simple android smartphone and it worked alright. So fading out the departing image while fading in the arriving one doesn't seem to be a problem anymore for even less powerful browsers.

[molendijk]

I just noticed that the DD-script doesn't make use of the transition CSS3 property (-webkit-transition: opacity ns; -moz-transition: opacity ns; -o-transition: opacity ns;
transition: opacity ns) for fading between images, but uses a background-color (plus javascript) instead for that purpose. (This CSS3-property makes it very easy to fade out an image while fading in another one). That might explain the whole DD-problem of non-fluid image-transitions when everything is set to 'transparent'.

[jscheuer1]

Your demo functions very well that I could see in current Opera. I will probably have a closer look later. CSS3 was not a viable option when UFade was first conceived, probably not even when it was first converted to jQuery. Even today, depending upon the environment/target audience, it could be a poor choice. But it is coming more and more into its own.

I also wanted to mention (from earlier) that I didn't think you were being rude. I was just unsure if you had noticed that I had already conceded the point you were making. But since then I'm wondering if I precisely understood that point. I thought the problem with transparent backgrounds was primarily bleed through, not uneven fading. But we've been covering at least a couple of issues relating to transparent backgrounds in fade transition slideshows. I am aware how unevenness of transition can arise under certain circumstances. If the first method I mentioned is used, it's not really an issue, and even the second method not so much these days as it was some time ago. IE I believe is now the worst at handling simultaneous animations smoothly.

[jscheuer1]

This all got me to thinking about making my own css transition based slideshow and about modifying the Ultimate Fade-In slideshow to use css transition for the animation of the opacity changes in it. The latter especially because of all the features it already has and the others I've added to it over the years. Well It was a piece of cake. Here's an update of the latest version of the script, set to use css transition animation instead of jQuery animate, and to use it in such a manner that having a fully transparent background should work (only tested with different sized images, but should be fine with various opacity images as well) just use this script:

fadeslideshowcss.js

And don't forget adding this css to your page's stylesheet:

#fadeshow1, #fadeshow1 .gallerylayer {
	background-color: transparent !important;
	transition: opacity 2.5s;
}

where fadeshow1 is the wrapper id (wrapperid) for your gallery. You can adjust the transition rate as desired, 2.5s seemed fairly optimal to me, but with different slideshows one may want to transition faster or slower.

[molendijk]

This is a great improvement of the script. We don't need backgrounds anymore for smooth transition between images. Some remarks though.

To be on the safe side it's perhaps better to use:

-webkit-transition: opacity 2.5s;
-moz-transition: opacity 2.5s;
-o-transition: opacity 2.5s;
transition: opacity 2.5s;

rather than simply:

transition: opacity 2.5s;

Adding something like:

.gallerylayer {
background-color: transparent !important;
}

doesn't garantee that the backgroud will be transparent as long as the js-file has:

setting.$wrapperdiv=$('#'+setting.wrapperid).css({position:'relative', visibility:'visible', background:'black', overflow:'hidden', width:setting.dimensions[0], height:setting.dimensions[1]}).empty() //main slideshow DIV

because js-styles may (and often will) override css-styles, as in:

<body style="background: red!important">
<script>
document.body.style.background='yellow'
</script>

which will give a yellow background, not a red one.
In fact, we don't need:

.gallerylayer {
background-color: transparent !important;
}

at all for a transparent background. What we need is:

setting.$wrapperdiv=$('#'+setting.wrapperid).css({position:'relative', visibility:'visible', background:'transparent', overflow:'hidden', width:setting.dimensions[0], height:setting.dimensions[1]}).empty() //main slideshow DIV

in the js-file, if we want a transparent background.

Second, if we want a responsive show with dimensions given in percentages, we should not have:

.gallerylayer img{
width: 100%;
height: auto;}

(given at http://www.dynamicdrive.com/dynamici...nslideshow.htm, not given by you)
but:

.gallerylayer img{ 
max-width: 100%;
max-height: 100%; 
}

On a side note, if we use percentages for 'dimensions', then the descriptions for the images may be longer than the images themselves, since the container for the images may be wider than the images. In that case, it's better to give the container-div a border, and to center the descriptions. Centering the descriptions can be done like so:

imagearray: [
["http://www.dynamicdrive.com/dynamicindex14/shockwave/images/1.jpg", "", "", "<div style='text-align: center'>There is beauty to be found in nature not just in grand landscapes, but in the petals of an unassuming flower</div>"], etc.

Demo here.

[jscheuer1]

Your demo has missing images here, is that intentional? The script already allowed for that, showing the browser's default broken image icon in most cases. I'm working on a customized demo that I eventually want to fine tune to optional usage of whatever the end designer desires. It's not even finished with customization (still has some flaws in it's current incarnation, but takes care of a lot, at least for what it's doing - one thing I would say though, if you're using css to do anything, you always must take care not to override what you're doing. That goes for working with this script or anything else. Oh, and the strength of using css transitions is that all modern browsers now support the generic usage. That said, your comment about using vendor specific usages (styles) has merit if you're working in an environment that demands that. Demo so far (still has a few glitches, working on it):

http://jscheuer1.com/garden/indexcss.htm

Uses a more customized version of the script - and is a work in progress. That all said, the script I published in my last post in this thread will work for most folks' applications, assuming they're willing to use some common sense, and/or work with it in cases where it might not be optimal right out of the box (basically - like any DD script).