JavaScript Animation and Browser Scaling


First time poster, long time reader. I first want to say thank you for your products and hard work. I love building eLearning with Storyline. 

Situation: I often use JavaScript to animate objects in Storyline. I have been using it for a while now and have always tested on all device types (mobile, tablet, PC). In previous versions of Storyline, if I moved a Storyline object on the slide using a JavaScript animation, the animation would scale with the browser window relatively. With the most recent update, when I scale the browser, any object that I have moved using JavaScript does not scale with the browser. As a development team, we have used JavaScript animation extensively and this would break a lot of our existing modules if we ever needed to update them. Moreover, going forward it's unclear whether we'll be able to use JavaScript animation reliably at all due to this scaling issue. 

Here are two examples. The first example is published from Storyline version 3.25.18009.0. In this version the animations scale with the browser but maintain their relative value to the black line. 

The second example is from version 3.34.20804.0. In this example, you'll notice if you resize the browser that the yellow rectangle does not scale relative to the black line. If you make the browser window small enough (e.g., iphone size), the yellow rectangle disappears completely to the right. 

Example 1: v.3.25.18009.0

Example 2: v.3.34.20804.0

This is quite a big issue since many of our modules use this type of animation. 

Can your development team shed any light on what might have changed in the most recent update as it pertains to the user manually resizing the browser window? 

12 Replies
Lauren Connelly

Hi Justin!

First off, thanks for sharing your kind words about Storyline! We think so too! 

Secondly, I'm happy to see you've submitted a case and working with Jopney, one of our Support Engineers! You're in good hands!

I'll be following along to see the outcome!

Curtis, I'd recommend also working with our Support Engineers! Please use this link to share your file and begin troubleshooting.

Curtis Wiens

We were holding off on updating Storyline because of the web object resizing issue. in the mean time we started using JS animations in SL which are now having the issue Justin describes above. How long is it reasonable or possible to keep using this now almost year old version of Storyline?

I am on v.3.25.18088.0




Alyssa Gomez

Hi there, Curtis,

I did a little digging, and I found your case from earlier this year where you reported having web object scrolling issues on an iPhone – is that the same problem you're referring to here? The good news is we're prioritizing a fix for that issue!

We're making improvements to the Articulate 360 sign-in experience. As a result, all users need to install the latest version of the desktop app soon. If you haven't done so by December 2 you'll automatically be signed out and prompted to install the update before being able to log back in. If you have any questions, we're happy to help!
Curtis Wiens

Oh! that is good to know we will have to make some adjustments here. The new issue is around tweening Storyline objects using the Javascript trigger. 


We bring in the Greensock library using a webobject in a child slide. 

On the Slide level we get the aria label from the accessibility panel:

var item = $('[aria-label="storylineshape"] svg')

That allows us to then tween that storyline shape using GreenSock:

function go() {,4,{rotationX:90,rotationY:45,x:900,ease:Elastic.easeOut})


This has worked beautifully and we can do some amazing animations directly in storyline without the need for web objects. 

What is happening now is we cannot tween things TO and X or Y value. Justin has a great example above. It does not respect the stage being resized any more. That is true of any JavaScript positioning in the x or y not just greensock as Justin is showing above. 

Math Notermans

As i replicated the samples above of Justin to see how to fix it i up till now only found 1 solution.

Using GSAP3, i use gsap.getproperty to get the x of the 'Motion Path' shape and set a variable for anyother shape to move on x.

Like this:
var xPos_MotionPath = parseInt(gsap.getProperty("[data-acc-text='MOTION PATH']","x"));
var shapeToMove = $("[data-acc-text='rect2']");, {duration: 1.5, x: xPos_MotionPath});

Offcourse this doesn't really solve the issue, especially if on older SL-versions it worked, but at least a workaround for it.

KInd regards,


Math Notermans

As i noticed the behaviour mentioned by Curtis and Justin too...making position based animation with Javascript in Storyline tough... i just noticed an update in GSAP that might fix these issues.

getRelativePosition( );

Thus converting from some local coordinates to some other elements local coordinates.
I didnot update my Gsap libraries yet, but for sure gonna test and try this...

And Zand

Here is another possible workaround.

The idea is to get the window size from $(window).width() and $(window).height(), then compare the width/height of the slide with those of the window and multiply the coordinates of the motion path by this number.

Depending on the size of the browser, we should calculate the ratio of the widths or the heights, because of the empty space between the slide and the edge of the window. For the slide 1280x720 without a build-in menu, I found that it should be like this: if the aspect ratio of the browser window < 1.77 => we should use the width, if > 1.77 => we should use the height. But this will be different for a slide with different proportions and if we use a built-in menu.

It works perfectly with the GSAP MotionPathPlugin if we convert compound path to bezier points with snap.svg.