knockout text | css clip-path

[quastiqualle]

hey there lovely people 🌿 🌾

 

i am working on a knockout text animation using css clip-path. it works perfectly fine in chrome and zooms in right to the center, which is what i want. in safari however, it goes bonkers. please test it out yourself using the codepen or have a look at the videos below. i have tried so many different things. but i cant find any gsap setting that fixes this. would love to get help here.

 

i am definitely dependent on clip-path for this animation as the final slide layers will include fullscreen videos (not in this reduced version). so basically what i want to achieve is having the video of the current slide play in the background, while the video of the next slide already plays inside the knockout text mask. then by scrolling through the site, you go from one video to the next, flying through the text in the centre.

 

there is one more issue i am facing thats probably not related to gsap. the animation breaks when resizing the viewport. if anyone is able to help here as a bonus, it would be more than welcome.

 

thank you so much everyone.

best wishes,

jaro

🤍

 

----

 

 chrome v116 ✔️

safari v17 💥

 

See the Pen PoXJdNJ by jaro_io (@jaro_io) on CodePen

[SteveS]

I'm on Firefox and it looks the same as the Safari video you posted.

[quastiqualle]

@SteveS thanks for getting back to me. yeah currently it only works in chrome. safari, firefox and other browsers seem to interpret the code differently. any ideas what could be happening?

[SteveS]

Not really. I'm not familiar with the method being used.

I tried changing the transformOrigin from "50% 50%" to "0% 0%" and it now works correctly on Firefox.

 

I'm not an SVG expert so I don't know why this would be different across browsers, but I do know that the way the SVG is placed into the DOM is strange. It looks like the viewbox is only in the top left but the SVG content takes up the full screen.

Is there an article you are basing this off of that I could read?

[Rodrigo]

Hi,

 

I'm also not an expert in SVG, but this could be related to what Jack discussed on this thread:

 

On top of that your SVG doesn't have an internal coordinates system which is normally given by the viewBox property, which could also be a reason for this behaviour. Have you tried giving the SVG tag a viewBox attribute in order to handle the origin point using the svgOrigin property GSAP offers?

 

svgOrigin

[Only for SVG elements] Works exactly like transformOrigin but it uses the SVG’s global coordinate space instead of the element’s local coordinate space. This can be very useful if, for example, you want to make a bunch of SVG elements rotate around a common point. You can either define an svgOrigin or a transformOrigin, not both (for obvious reasons). So you can do gsap.to(svgElement, {duration: 1, rotation: 270, svgOrigin: "250 100"}) if you’d like to rotate svgElement as though its origin is at x: 250, y: 100 in the SVG canvas’s global coordinates. Units are not required. It also records the value in a data-svg-origin attribute so that it can be parsed back in. svgOrigin doesn’t accommodate percentage-based values. 

 

Hopefully this helps.

Happy Tweening!

[quastiqualle]

hey you two! 🌻
during my research i learned the following.

i hope this explains it a little better and maybe it can help somebody else in the future.

since i’m not rendering the svg visually, but using it solely for a clip path applied to html elements, the viewbox doesn’t play a role in determining the size or position of the clipping area. the same rule applies when setting a size (width, height) or position (x, y) for the svg. in this specific use case, these things have no effect. the svg is merely a container for the clip path definition. instead, the css transformations applied to the #mask element are what actually determine its final size and position.

 

one more thing worth mentioning is the clipPathUnits attribute, which is currently set to userSpaceOnUse (browser default). there are some big advantages in using it over the more commonly used objectBoundingBox. because it allows to keep the aspect ratio of the text and target its size, position and other properties via css. i have created another pen to show the difference in action (again, difference between chrome and safari/firefox).

userSpaceOnUse

the coordinate system for the clip path will be the same as the svg's coordinate system. however, since i’m positioning and scaling the clip path using css, this setting will effectively let my css styles dictate the final size and position.

 

objectBoundingBox

the coordinate system for the clip path will be scaled and positioned to fit within the bounding box of each individual element that uses the clip path. in my setup, this would mean that the coordinate system for the clip path would adjust to the dimensions of my slides. values like x, y, width, heigh and font-size within the clip path would be interpreted as fractions (0 - 1) of the slide’s bounding box.

 

----

 

so to summarise, @Rodrigo i don’t know if using svgOrigin would have any effect in my use case, as i am not using the svg’s global coordinate space. and @SteveS that was a great catch. yes, i can confirm changing transformOrigin to 50% 50% will indeed fix the issue in safari & firefox. however, i would still like to understand why. do you have any idea?

 

i would love to find a universal solution and only as a plan b build workarounds for specific browsers. however, if i need to go this route.. are there any built-in tools within gsap to check for that?

 

thank you all!

🪲 ✨

 

See the Pen rNoYLep by jaro_io (@jaro_io) on CodePen