Leaderboard

So decided to do performance test with Custom Ease vs Bezier, and also show look and feel. Performance looks very similar. Here they are if anyone is interested: Any and all feedback/ideas are welcome! Thanks!

It's pretty tough to troubleshoot without a demo and this seems like a ScrollMagic problem rather than a GSAP issue. ScrollMagic uses GSAP, but it is not a GreenSock product. You may want to look at the ScrollMagic refresh() method. http://scrollmagic.io/docs/ScrollMagic.Scene.html#refresh You could also skip ScrollMagic and look at using the Intersection Observer. https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API You could also post your ScrollMagic question here: https://github.com/janpaepke/ScrollMagic/issues Happy tweening.

Hi @adimension, Welcome to the GreenSock Forum. This is a case for SVG and ClipPath and the convenient GreenSock morphSVG ... Some weeks ago ... Happy tweening ... Mikel

Yes, the site you referenced is using TweenMax. The demo @mikel gave you is a fantastic starting point... if not an end point of what you need to do. GSAP is an animation engine, which means you are still required to write code to tell it what to do, as such it is virtually limitless in its flexibility and complexity of use. Its not like fancybox or some jqueryplugin that automagically takes a few DOM elements and spits out a fully functional widget or slideshow for you. Reading the getting started article should definitely help explain how it works.

Hi @alfianridwan, no problem at all. I'll break down a few things that are happening here ... First and foremost ... I'm using jQuery to make some tasks much easier. If you're new to JS, you may or may not know the ins and outs of cross-browser compatibility. In short ... jQuery fights that battle for us. So your questions and my answers are addressing jQuery $('document').ready( function(){ Is just waiting for the DOM to be ready before we do anything. $('.blog-card img').each( function(){ So .each() is a jQuery method that allows us to iterate over the matched set ... in this case, all elements returned with the selector ".blog-card img". So what happens here is the DOM is scoured for all <img> within elements with the class ".blog-card". Now that that images are returned as a set, jQuery's .each() will iterate over each one to perform all the actions with the .each(){ }. In plain english, here is what is happening within that, Find the <img>'s nearest (up the DOM tree) enclosing element with the class "blog-card". This is the card that the image belongs to. Within that card, inject an element before all its children ... a new div using the current <img>'s (i.e. the <img> currently being referenced as we iterate with .each() ) src as the css background-image move the <h2> within the card to now be a child element of the new <div class="blog-card-background"> Add in a new div to represent the "close" X in the top of the expanded card. remove the <img> from this card (we no longer need it) Now, for the why to all the above We do this just to make a simple reference rather than asking jQuery to look up the tree many times. In this particular case, the hit is negligible. But it's good practice that if you are going to ask for something multiple times ... simply create a variable to hold it. For me, positioning and animating a div with a background image applied is much easier than positioning and animating the <img> itself. For example ... applying an image as a background with background-size: cover and background-position: 50% 50% tackles so many issues on its own when dealing with responsive images! Because the new <div class="blog-card-background"> is positioned relatively, it allows us to stick the (now) absolutely positioned <h2> to the bottom of the image (with padding) by using the CSS bottom property without any concern for how many lines the <h2> may be. We have to be able to close it! No use in keeping it in the DOM ... we are now using that image as a background for the <div class="blog-card-background"> You'll notice we did a lot of manipulation at this point with jQuery. But why? Why not just do all of this in the markup? Well, for several reasons. If javascript isn't available (or some other script causes it to fail), we want the user to have something that a. looks approriate and functions as expected (i.e. click a blog card and navigate go through to that blog post as a new web page) b. doesn't present interface elements that perform no action My basic rule ... if Javascript is required to interact, then Javascript is responsible for creating the element. So make sure it's usable without JS. $('#some-blog').on( 'click', '.blog-card.inactive', fucntion(){ ... This one is a bit nuanced, but I'll explain here. We want things to happen when something is clicked. Someting "A" when clicked in a "card" state and something "B" to happen when clicked in an open state. Now, I could have simply used ... $('.blog-card.inactive').click( function(){ ... Buuuuut, that does something a bit unexpected. A unique click handler get's bound to each matching element from that point forward .. regardless of losing the "inactive" class down the road. You might say, "that's OK, we're using a different element to close the open state.". And that's true ... but, clicking anywhere else anywhere within, in this example, the open blog post would still cause this handler to fire. We could do some detection to remove this handler while in an open state and rebind after. But it's so much easier to do $('someSharedParentElement').on( 'click' , 'target', function(){ ... because it creates a single handler for all matching elements AND allows the handler to be bound to dynamically created elements down the road! Think of a blog with infinite scroll, for example. And, when the "blog-card" has its class changed from "inactive" to "active", this event handler is no longer bound. When it goes back to "inactive" it is bound Noice!

Had a bit of time this afternoon ... here is a quick crack at it. A few notes ... the HTML, CSS, and JS are setup to support progressive enhancement. If JS isn't available, you'd simply get a tile with a background image and an overlaid title. Clicking would push through the the target URL. jQuery does some restructuring to get better control from both a CSS and a Tweening perspective. I'm also using jQuery to handle the simple click events. I'm sure adjusting some timings (or even tween orders) would produce a better result ... I haven't gotten there yet Big note ... I wouldn't look it here in the embedded CodePen ... I would go out and view it in a narrower viewport.