Shaun Gorneau

OK, I'm sorry ... I'm still not sure what you're looking for. To me, a slideshow, a menu, and a timeline could describe wildly different things. Do you have an example of something that illustrates what you're looking for? Here is a pen showing how to easily assign button clicks to hide/show actions on specific elements. https://codepen.io/sgorneau/pen/LWWgeb

I'm sorry ... I'm not sure what you are asking here. Do you want each button to display a corresponding box while hiding the others?

Glad to help.

You can start with a paused tween, set the .progress() to any 0-1 value, grab the values, and then set the progress.() back to 0.

Absolutely. If these objects are all placed in a determined way, then they all would have the same "to" points. If they should all be random and then meet at the same point, you can generate them then give them all the same "to" points ... or, position them all at the same point to start, and then set random "from" points. http://codepen.io/sgorneau/pen/MppKPz

I've forked the pen above to introduce "snap points". What I've done is calculated the width of 1 tile divided by the width of the animated container to get a decimal representing the increment on a 0 to 1 point scale (which is appropriate for the timeline) for each tile movement (just multiply that number by 100 for the 0-100 scale value the jqueryui slider uses). I also have an array of "snap points" built using that increment decimal times `var i` in a loop up to the number of tiles in the animated container; which is the total number of tiles minus the number visible at any given time ... in this case, 9 total with 3 visible ... that gives us 6 snap points. Lastly, I have a function that looks through an array (our snap points array in this case) and finds the closest value it contains compared to any number passed to it. So, when the UI slider is done "sliding", its position/100 is passed to this function, the function looks through the snap points array to find the closest value, that value is returned, the timeline is animated to that value and the slider's position is animated to that value*100. Important thing to note here ... I have set `ease: Power0.easeNone` (line 44) on the timeline ... easing will interfere with the 0 - 1 scale with regard to equal, incremental chunks for the snap points. I am, however using an ease when tweening the timline progress to the snap point value (line 71). http://codepen.io/sgorneau/pen/mWRZob

Ok, understood about the need for a timeline. To address the "Q1: Unfortunately it finishes outside the container ... " I've forked your pen and modified the CSS quite a bit so you don't have to rely on calculating and setting a width for the container ... CSS will simply allow it to layout and then we can just "grab" the width. This will happen no matter how many boxes are placed within. I've modified your JS only a bit. All modifications have notes as to why I did something (pretty sure I commenting everything), so it should be pretty clear. http://codepen.io/sgorneau/pen/bqgzmJ?editors=0110 As for "when the user releases the slider handle, the group should center up the image closest to the center" ... that can certainly be done by animating to multiples of a box width ... but the current layout doesn't really make use of a "center position" as it currently displays approx 3.75 boxes. [Edit] My last statement was in regard to your first pen, I hadn't realized there was a second

While I'm not using swipe interaction on this, it might be helpful. http://codepen.io/sgorneau/pen/RpKKmN?editors=0010 One big difference here is I'm not using a timeline ... I'm using Tweens to move in either direction +=/-= the width of one "slide" and jumping to initial and (calculated) end states when wrapping. I say calculated end state because, not being a timeline, the end state is the width of a slide * the number of slides. These slider slide sizes and end position are recalculated when the browser resizes. Essentially, what I'm doing here is the following The markup output from the CMS is a straight-forward set of <div>s, one for each image associated with a featured blog post (you can see this in the HTML window of the pen) Some fairly straightforward styling to get them setup in a horizontal strip Javascript (in this case using jQuery) to take the last two blog posts and prepend them to the strip and take the first two blog posts and append them to the the strip. This is to solve the problem of empty space at the bounds of the original set to make a "seamless" trip around As the user advances "forward", when the first appended slide is animated in, the slider resets to the initial position of the timeline As the user advances "backward", when the last prepended slide is animated in, the slider jumps to the calculated end position To explain, imagine that the markup initially setup the slides as 1 2 3 4 5 The javascript then prepends/appends -4 -5 1 2 3 4 5 +1 +2 The slide show "displays" -5 1 2 to start as the user advances forward they would see in order -5 1 2 > 1 2 3 > 2 3 4 > 3 4 5 > 4 5 -1 .... if advanced forward from here, the animation would reveal 5 -1 -2 and then immediately jump to -5 1 2 (the initial state) In the reverse, from the initial state -5 1 2 back to -4 -5 1 would animate in and then jump to 4 5 -1 (the end state)

Honestly, one of the best places to look for inspiration is CodePen. The fact that you can see how it works in a nice package is a huge plus, but, regardless of that, CodePen is an incredible showcase of inspiring work. Other places to look would be Awwwards https://www.awwwards.com (I don't always agree with the awards themselves, but you can find some pretty good gems in there) A List Apart https://alistapart.com CSS-tricks https://css-tricks.com Noupe https://www.noupe.com (I used to frequent this often, haven't been there in a long time though) Dribbble https://dribbble.com (another good place to spark ideas, although can be a little infurating if you actually want to contribute)

If you need all sections of a book page to be zoomable based on a defined grid, I whipped up a quick pen that does this using a single image tag in the markup. - JS builds a grid of <div>s - Takes the single image and applies it as a background on a defined number of tiles - It then positions that image background on each tile to create a mosaic representing the single full screen image - Clicking any of the tiles simply scales that tile One thing I didn't do was the logic to center the scaled tile ... just to get the above idea across quickly. http://codepen.io/sgorneau/pen/wJgKyG?editors=0010

I've been working with JS for about 10 years now ... but I'm not going to even try to fake it ... OSUBlake is the JS rockstar here! One of the things I've tried to do over the past few years is write JS (and HTML & CSS too, for that matter) as generically as possible and allowing data-attributes to be the value containers for ever-changing environments. This helps (me) keep the JS clean and lean and also gives me a nice place to inject initial values from the server. I work with CMSs a lot and I really like to give control to content teams to create dynamic, configurable elements, and for me the cleanest way to translate their "settings" to a template file is to pass those initial values into data-attributes that the JS can then hook into rather than injecting <script> blocks to pass those values. When watching a live DOM, it's also nice to see those attributes updating right on the elements, especially when addressing an issue. But, more importantly, to OSUBlake's and PointC's points ... it's all about identifying and addressing the problem/challenge (the "what") and much less about JS (or any language). Once you get comfortable breaking it down into logical/modular chunks, even written in plain English, the "how" part starts with poking around in API documentation (vanilla JS, jQuery, GSAP, etc.) and eventually you do that enough to not have to make too many trips back into the docs (side note: I still make trips to the docs ) Once you separate the logic from the language(s) in terms of a mindset, it becomes much more clear which steps you need to take ... and then you determine what markup, functions, methods, and syntax will get you there.

Glad I could help!

This is easily overcome by placing a small amount of JS in the head to assign a "js" class to <html>, and then use html.js .some-selector{ /* Whatever CSS properties you use to "hide" */ } This way nothing is hidden if JS is unavailable.

A few things I would do to make it a bit more straight forward ... 1. I would change the classes of `image1`, `image2`, etc to ids. Then I would put a data-clone-of attribute on the clones themselves (this helps tie them to their clone source) 2. I would then use the position of the original item as the x/y properties of a new tween and put an 'onComplete' property in that tween whose function removes the clone. I think this would be simpler than reversing the timeline and then setting some sort of ticker/conditions on 1) the timeline being reversed and 2) its position being polled in order to know when to remove the object from the DOM. You can see here what I'm suggesting http://codepen.io/sgorneau/pen/bqBrpa The changes I'm proposing are in your click handlers $('.holder').on("click",function() { ... $('.wrapper').on('click', '.closeX', function(e) { ... All new lines marked with `// New code`

One thing I would offer is, rather than looping through the navigation <li>s and assigning a click action to each independently, I would put a generic class on each (`nav-opt` in my example) along with an index data-attribute to quickly get its "place" and navigate with the same logic you used. I forked your pen and added a bit where you are constructing the navigation to add the generic class and the data-attribute, and modified your click event handler at the end. http://codepen.io/sgorneau/pen/ZeBKKW?editors=0110

I use photoswipe in a lot of projects (here for an example) ... it really is perfect for gallery setups and handles all the touch/swipe/click-drag/keyboard interactions & animations along with a host of other considerations. It's a solid choice.

Yes, of course! Aye, not sure what I was thinking there

All you have to do is set the Tween in your click handlers. In a fork of your pen, have a look at lines 35 and 47 with a couple of notes on 17 and 28. http://codepen.io/sgorneau/pen/oZzJEB?editors=0010

You can use a function to return a property value. http://codepen.io/sgorneau/pen/NpRwpj

Hi @rideforthebrand To get equal "rate", and because the "distance" of any sentence is determined (its width), that leaves us to calculate "time" for the tween. http://codepen.io/sgorneau/pen/mWEddP

No, I get that. I meant more as an "until the issue itself is addressed" type of solution since +-.001 in terms of seeking should be negligible.

With whatever UI you are using to let them control the playhead, you could always add .001 to the calculated value ... maybe? I can't imagine the user has control to the 1000ths.

You've got a 0.4 position set on the tween relative to its timeline ... so nothing *should* happen before 0.4 The timeline is playing, but the tween will not kick in until 0.4 ... so seeing 0.3 should show that it hasn't begun. [EDIT] I completely misread the issue ... sorry, disregard my comment

The problem is that when move() is called, the selector addresses both elements ... but, in the case of the one being wrapped, the DOM has changed after that element was referenced (and is now gone).

No matter where this conversation goes ... I would like to note that this is one of the most entertaining posts to date MO-MO-MONSTER BONUS ... lol