alexr8

Hi @Rodrigo thanks for the extra examples. In the end this didn't quite do what i was looking for but it did help get my brain moving! As i need to set attributes on every item, not just one each side of the active element i went a different route which you can see below. I'm not sure if its entirely efficient - but essentially onchange I: - set the active item to be the highest zindex - loop forwards from the active element for half the length of the boxes array, setting zindex in decreasing increments - loop backwards from the active element for half the length of the boxes array, again setting zindex in decreasing increments - in both loops i wrap around the array with simple resetting of the loop increment if i get to the end or beginning of the array respectively (sure there might be a smarter way of doing this with modulo maybe?) I've tried to keep it so all values are relative to the length of the boxes array, so it doesn't really matter how many 'boxes' you add it should still continue to work. One thing that would be useful in the GSAP provided 'horizontalLoop' helper is to have a callback that is run when it is finished its calculations - e.g. 'onChanged' vs 'onChange'. If i try to use draggable or toIndex(), or click next/prev very quickly, it triggers the onchange function for every slide it passes by which kind of breaks things in this instance where i'm trying to do quite a lot of calculation, and really it only needs to be applied once we've reached the slide we want to finish on. Alternatively is there another way i could 'cancel' the current calculations if onChange is triggered again while its still running a previous calculation? Maybe the issues is some of my variables are defined within the onchange scope but should be defined outside of it so they can get overwritten? Any suggestions or pointers to improve this would always be welcome! https://codepen.io/alexr8/pen/WNWWoMg

Thanks @Toso i did actually explore those a little while back - but they both seemed intrinsically tied to scrolling which i want to avoid. All the calculations seemed to be based off of scroll amounts which i had a stab at unpicking but couldn't separate out the logic. The other thing that tripped me up was when I looked at their code i couldn't see where z-index was being set - it seems to be set once on each element to 100, but actually interacting with the demo the z-index sometimes gets set in increments and sometimes switches to auto. I think maybe its not noticeable as only the front 3 overlap in those demos.

Hi All, I was wondering if you might be able to give me some pointers on how I might achieve the following: I'm looking for an infinitely looping slider where each item overlaps in a coverflow style. The center item would be highest z-index, then each box either side is a layer back, and each box to the side of those are a layer back and so on. I've been playing around with the horizontalLoop() helper, which works really nicely. My first thought was: if the boxes get removed and added to the dom before/after the active element, i could then loop through all the boxes, and everything before reaching the active element i incrementally add to the z-index, and everything after i decrease the z-index, and just set the z-index of the active element suitably high enough so its always in front. However as the elements are positioned using translate this approach fails (items that visually appear before the active element might actually be after it in the dom). Also i'm not convinced if my approach would've been very efficient? I wonder if there might be something else in horizontalLoop that i could hook into to work out which items are positioned left of the central element, and which are after but I'm getting a bit stuck. Any help or ideas would be amazing. Thanks!