Can I use vw in "end" except px?

[mr.G]

Hello everyone!

Please tell me. Can I use vw (or any other) in "end" except px?

If the answer is no, is there another way to get a similar result?

 

gsap.timeline({scrollTrigger: {
  trigger: "#camera",
  start: "center center",
  end: "+=250vw", //???????
  pin: true,
  scrub: 1
}});

Best regards,

Mr.G

[mvaneijgen]

It seems like you can only use pixel of % values as stated in the docs https://greensock.com/docs/v3/Plugins/ScrollTrigger

 

And discussed in this topic.

 

But you can of course use any dynamic value, so if you get the window.innerWidth which is equal to 100vw and multiply it by 2.5 you'll get your 250vw which gets you the desired result. Hope it helps and happy tweening! 

 

See the Pen vYaPbKV by mvaneijgen (@mvaneijgen) on CodePen

 

Demo with VW units not working ❌ 

 

See the Pen oNMVmXq by mvaneijgen (@mvaneijgen) on CodePen

[mr.G]

8 minutes ago, mvaneijgen said:

But you can of course use any dynamic value, so if you get the window.innerWidth which is equal to 100vw and multiply it by 2.5 you'll get your 250vw which gets you the desired result. Hope it helps and happy tweening! 

Thank you!

[akapowl]

 

Like @mvaneijgen mentioned, vw units are not valid in ScrollTrigger's start/end, so you could just use JS to get the value you need.

 

Just a headsup;

 

This (as suggested)...

 

end: `start+=${window.innerWidth * 2.5}px`

 

...doesn't look quite right to me. If you want to use a value relative to the start, it should start with '+='

 

end: `+=${window.innerWidth * 2.5}px`

 

Also, I'd suggest to use function based values, when you get the value like that, so ScrollTrigger will properly adjust the value on resize.

 

Here is another rather simple example. Hope it will help.

 

See the Pen jOpJdBW by akapowl (@akapowl) on CodePen

 

[iDad5]

Small caveat here from me, as I'm fighting with this issue for a while now:

3 hours ago, mvaneijgen said:

window.innerWidth which is equal to 100vw

 Is true in most cases, but not always:

 

On (mobile and tablet) browsers that overlay the content with interface elements like the address-bar, which will be retracted when scrolling, this is not true.

 

Here is a short list of things that might be helpful to remember:

• window.innerHight (and the equivalent innerWidth) resemble the total space of the viewport, including visible scrollbars.
• document.documentElement.clientHeight (and width) measure the space excluding visible scrollbars. 
• 100vh is the same as window.innerHight as long as there is no expanding browser interface.

If there is an expanding browser interface, usually only the height is affected, and usually 100vh resemble the height of the viewport once the dynamic interface is retracted/hidden. (But there is no guarantee, as the specs leave it to the browser vendors how to deal with it.)

 

3 new units that are already quite well-supported come to the rescue, however: 

 

• 100svh resemble the height of the visible/usable viewport when the interface is fully present.
• 100lvh resemble the height oft the visible viewport when the dynamic interface is fully hidden.
• 100dhv resemble the height of actually the visible viewport at every moment. (It is not guaranteed to be updated as fast as the browser renders, however.)

An illustrated in depth description can be found here: https://github.com/web-platform-tests/interop-2022-viewport/blob/main/explainers/viewport-units.md

 

[mr.G]

@akapowl thanks for the tip, i fixed it 🤙

@iDad5 In this case, I did it only for the desktop, I disabled it in the tablet and mobile.
But thanks for the advice! I will take this into account in the future