Responsive tweens with function-based values

[katerlouis]

Please forgive the lack of a pen. Deadline– ...

It's gonna work like this! I promise–

 

var tl = new TimelineMax() 
	.to(elem, 1, { y: function() {
    	return $(window).height() / 100 * 50;
    } });


$(window).on("resize", function() {
  // refresh the timelines tween 
});

 

How can I force tl to execute the tweens function and therefore recalculate the y-value?

 

 

Thank you for your help!

[GreenSock]

Well, technically you could just invalidate() the timeline/tween to force it to re-record all the starting/ending values on the next tick, but you could also just create a new tween each time and simplify it like: 

 

$(window).on("resize", function() {
  TweenMax.to(elem, 1, {y:$(window).height() / 100 * 50});
});

 

[katerlouis]

The tween I want to "responsivize" / react to resize is part of a big timeline with labels I tween to etc. pp.

 

Wouldn't invalidating completely reset the tl? I need the progress to stay at label xy or maybe even keep playing while resizing? 

 

And it is more of a general question when these function-based values update. Because if they don't I don't see the huge advantage here.

[Sahil]

You can use modifiers plugin to calculate values before applying them so your tween will continue playing on resize as if nothing happened. Though if your current tween inside the timeline is not active then you will have to manually set it's position on resize.

 

 

See the Pen eMNopW?editors=0010 by Sahil89 (@Sahil89) on CodePen.

 

[katerlouis]

On 12.3.2018 at 11:53 AM, Sahil said:

You can use modifiers plugin to calculate values before applying them so your tween will continue playing on resize as if nothing happened.

 

This sounds promising; I look into that.

How is the impact on performance with this technique? My instinct says it's rather heavy. I need to change a lot of tweens on resize–

[OSUblake]

Getting the window size inside a modifiers function isn't going to help improve performance.

 

$(window).height()

 

jQuery or not, it's still requesting the current window size. See what forces a layout.

https://gist.github.com/paulirish/5d52fb081b3570c81e3a

 

The window size should be stored in a variable.

[OSUblake]

Here's a demo I made with CSS vars. The --x and --y values are in vw/vh units, so it will be responsive.

 

See the Pen XEJMWE by osublake (@osublake) on CodePen.

 

 

 

[Carl]

Great demo, Blake. Very clever and cool!

[OSUblake]

Thanks!

 

It should be noted that animating CSS variables like that just changes the inline style, so it will work with multiple elements.

 

See the Pen OvbqXL by osublake (@osublake) on CodePen.

 

 

 

 

[GreenSock]

Really nice, Blake! 

[Acccent]

wow that's a new thing isn't it! I thought variables were exclusive to preprocessors. Great!

[OSUblake]

27 minutes ago, Acccent said:

wow that's a new thing isn't it! I thought variables were exclusive to preprocessors. Great!

 

Sort of new, but a variable in preprocessor doesn't work the same way because they are static and cannot be changed at runtime.

https://greensock.com/css-variables

 

And if you want to see the future, fire up Chrome and check out these experiments. Chrome needs to be version 65 or higher.

https://lab.iamvdo.me/houdini/background-properties

 

[OSUblake]

And I see some new experiments have been added. I love this one.

https://lab.iamvdo.me/houdini/random-bubbles-mask

 

EDIT: Actually, you might have to wait a couple of more versions to see that, or enable experimental web platform features in Chrome or Opera. Copy and paste this in your address bar.

 

about://flags/#enable-experimental-web-platform-features

[Acccent]

!!! this is a whole new thing to learn – gotta find out when to use it and when to avoid it. A whole new world of possibilities! Exciting

[OSUblake]

16 minutes ago, Acccent said:

gotta find out when to use it and when to avoid it.

 

I don't know if there is a reason to avoid them. From a styling point of view they're safe to use because CSS just skips stuff it doesn't understand.

 

.foo {
  background-color: green; // fallback
  background-color: var(--myColor); 
}

 

IE is the only browser that doesn't support them, so the animation won't work, but it won't throw an error.

 

But I would just disable all the animations in IE. Don't worry, your client won't check. 

[PointC]

2 hours ago, OSUblake said:

But I would just disable all the animations in IE. Don't worry, your client won't check. 

 

If someone is using IE, this is how you respond.

 

 

[Acccent]

On 24/03/2018 at 2:16 PM, OSUblake said:

I don't know if there is a reason to avoid them. From a styling point of view they're safe to use because CSS just skips stuff it doesn't understand.

 

What I meant by 'avoiding them' was more, like, when you learn about a new thing you get all excited about it and try to do everything with it – even stuff that actually doesn't need it. I can totally see myself reworking animations to add CSS variables everywhere even if they don't do anything at all to improve the animation in question. So, gotta watch myself