PDA

View Full Version : Can you put 2 slideshows on the same page



mcolton
03-03-2017, 12:54 PM
I'm using w3.css slideshow http://www.w3schools.com/w3css/w3css_slideshow.asp
I have 1 working slideshow right now.
Is there a way to put a second one on the same page.
Thanks

jscheuer1
03-03-2017, 01:05 PM
Not that one.

mcolton
03-03-2017, 01:43 PM
Thanks. Any suggestion for a SIMPLE slideshow with options for captions

styxlawyer
03-03-2017, 02:45 PM
This is about as easy as it gets and you can have as many as you like on a single page:

http://www.dynamicdrive.com/dynamicindex14/fadeinslideshow.htm

The only downside I have found is that you have to hack the JavaScript code to change the background colour as it's not possible to do it in the slide show settings and any attempts I made to do it with CSS failed.

mcolton
03-03-2017, 04:39 PM
Thanks. I was looking at that one too

jscheuer1
03-03-2017, 05:03 PM
You can use css to change the background color:


#fadeshow1 .gallerylayer {background-color: white !important;}

Where fadeshow1 is the wrapperid configured for the slideshow. Or omit the id selector from the style declaration and it will cover all slideshows.

styxlawyer
03-04-2017, 09:26 AM
Thanks John. I'll try that.

molendijk
03-06-2017, 07:20 PM
The background-color is the weak point of the slideshow in more than one respect. If you want the background to be transparent, then adding background-color: transparent!important to the styles results in a NON-TRANSPARENT BLACK background, because that's the default background given in the js-file. You can solve this problem by replacing all occurrences of background:'black' in the js-file with background:'transparent', but then another problem arises. If the images of the show don't have the same (original) dimensions - they don't have to, in a responsive version of the show - then fading from a bigger image into a smaller one gives a 'jerkish' non-fluid result. You can correct this by giving the show a non-transparent background (like background-color: white!important), but that's not what you wanted in the first place.

As for the possibility of having multiple slideshows on your page (post #1), you can use the same code over and over again by using a 'multiple-iframes approach'.

jscheuer1
03-06-2017, 08:03 PM
The overriding keyword !important has always worked for me, even to set the background to transparent. But you also have to set the wrapperid selector to transparent as well*, because, yep you guessed it, it's also black. But it's true that if the images are of different sizes or have their own transparent areas that differ from each other, you still have a problem. You either need a fairly major overhaul of the script or you need to give the .gallerylayers the same background as what is behind the slideshow, which if it's an image can be tricky as far as positioning it to line up goes, and if it includes other content, very tricky, if not impossible. I've set some of these up for folks with background images. It is quite tricky sometimes.

*ex:

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

This strategy might even be best for when you want a solid color background, as the wrapperid div will otherwise still be black and might show for a moment or two as the slideshow loads.

molendijk
03-06-2017, 08:53 PM
The overriding keyword !important has always worked for me, even to set the background to transparent.
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. So fluid image transition depends on non-transparency with this script.

molendijk
03-06-2017, 09:44 PM
Mcolton, here (http://mesdomaines.nu/demo_slideshow)'s a demo of what I said in post#8 about the multiple-iframe approach: one slideshow-script only but multiple slideshows.

jscheuer1
03-06-2017, 09:50 PM
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
03-06-2017, 10:10 PM
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
03-06-2017, 10:23 PM
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
03-06-2017, 11:45 PM
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 (http://mesdomaines.nu/demo_slideshow) 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
03-07-2017, 12:52 AM
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
03-07-2017, 04:58 AM
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
03-30-2017, 03:17 PM
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:

6161

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
03-30-2017, 11:46 PM
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/dynamicindex14/fadeinslideshow.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 (http://mesdomaines.nu/eendracht/slideshow_responsive11_scheuer_new).

jscheuer1
03-31-2017, 02:20 AM
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).

molendijk
03-31-2017, 09:39 AM
John, the missing images thing was not intentional. I fixed it.
Your last demo is working fine as far as I can see.

jscheuer1
03-31-2017, 03:06 PM
Thanks for the vote of confidence Arie. My demo has an issue in that, if you dismiss the descriptions, and then get them back, their auto height adjustment no longer works as intended. Also, once you dismiss them, the button for bringing them back (restore button) gets stuck in whatever location it was in, regardless of how wide or narrow the images are in subsequent slides. I think I can address both of those fairly easily. I'm also noticing today that the change in width of the descriptions could be smoother perhaps.

I think what you're saying about overriding style is flawed*. However, the script originally (a long time ago) allowed the user to configure the background as part of the options. I'm not sure why DD removed that. I guess he just liked black? Or he got tired of people trying to make it transparent? No idea really. I think it should be left out of the script entirely, so that it's easily controlled in the stylesheet without needing the !important keyword.


* It's true - your example with the body. But that's different. That's javascript overriding inline style, javascript always wins that battle as long as it executes after the browser has parsed the inline style. But the reason why .gallerylayer !important overrides don't work with this script is that it's also the wrapper div. so there are three divs that have the black background. One wrapper, which is accessed via it's id and the two layers, accessible via their common class name:


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

These cannot be overridden using the sort of javascript that the Ultimate Fade-In script uses**. But again, ideally I would say that it should have no background in the script. The user should be free to set that in the css without needing the !important keyword.


** They can be overridden with a subsequent !important keyword declaration in a javascript created and inserted (or simply in a normal) stylesheet, or by accessing the sheet via javascript and removing or changing the declarations, and perhaps by injecting an !important declaration inline via javascript. But U-Fade doesn't do any of that.

molendijk
03-31-2017, 05:35 PM
Yes, of course, inline styles are overridden by javascript executing after those styles have been parsed. Thanks, I didn't think about that.
I entirely agree that the background specifications should be removed from the script.

jscheuer1
03-31-2017, 07:16 PM
OK, I'm getting closer. Still some issues - not sure if I can put my finger on what they are yet - mostly involved with what happens when the page is resized, the captions can detach from the images. Oh, and still am using customization instead of options, but haven't tested how well the code will respond if the options/customizations I'm not using are employed and/or mixed logically for what's wanted. Might be better on that front than I fear.

In any case I'll be updating the demo shortly. You may have to clear the cache to notice any difference, assuming you did see the issues I mentioned before.