Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...
ReedBE

clip: rect() no longer animated in 1.18.3?

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts

Hello there,

 

I’ve just updated an ongoing project that makes use of clip: rect() animations to GSAP 1.18.3 and it seems that said animations no longer work, on any browser. Clipping values are properly set, but they are now changed instantly regardless of the wanted durations and easings. 1.18.2 seems to work fine.

 

 

Is that on purpose?

I know the CSS clip property has been set to be deprecated for a while, but given the poor browser support of clip-path, its so-so performances and its downright unstable behavior at times, I feel like clip’s days are not quite over yet.

See the Pen OyarJK by jonathan (@jonathan) on CodePen

Share this post


Link to post
Share on other sites

Hello ReedBE,

 

The CSS clip property has been deprecated and has been removed from the Web Standards spec:

 

https://developer.mozilla.org/en-US/docs/Web/CSS/clip

 

You must use the CSS clip-path instead:

 

https://developer.mozilla.org/en-US/docs/Web/CSS/clip-path

 

But maybe GreenSock's Jack could shed some light on this for you, please stand by?

 

:)

Share this post


Link to post
Share on other sites

Thanks for the demo.

Despite Jonathan being correct about clip being deprecated, 1.18.3 shouldn't cause your animations to break.

Very sorry about this. We will definitely look into it.

  • Like 1

Share this post


Link to post
Share on other sites

Hello ReedBE,

 

The CSS clip property has been deprecated and has been removed from the Web Standards spec:

 

https://developer.mozilla.org/en-US/docs/Web/CSS/clip

 

You must use the CSS clip-path instead:

 

https://developer.mozilla.org/en-US/docs/Web/CSS/clip-path

 

But maybe GreenSock's Jack could shed some light on this for you, please stand by?

 

:)

Doesn't clip-path not work in IE though?

Share this post


Link to post
Share on other sites

IE does not, and will not support CSS clip-path.

 

As far as MS Edge, it is backlog with medium priority to get supported. You can follow the status here:

 

https://developer.microsoft.com/en-us/microsoft-edge/platform/status/masks

 

You can leave a vote on there to show you want MS Edge to support it.

 

https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/6261341-css-masking

 

And GSAP has nothing to do with the CSS clip being deprecated, that has to do with the W3C and WHATWG.

 

:)

  • Like 2

Share this post


Link to post
Share on other sites

Thank you all for your answers.
 
To get back to Jonathan though: as I said, I know the clip property is a goner, but I really do feel like clip-path isn’t quite there yet. Besides being unsupported by the latest versions of IE and Edge (which already makes it a no-go in my case), I’ve experienced terrible performances with it in Safari and atrocious random graphical glitches in Chrome when animated via an inline SVG, which you kind of have to do if your want to handle Firefox as well.

 

As much as I’d love to be able to use clip-path for mask animations, I think there’s a reason why most heavily animated websites still use clip when a canvas-based animation is not an option.

Share this post


Link to post
Share on other sites

That behavior your seeing has nothing to with GSAP. CSS Animations using @keyframes and CSS transitions render the same way using clip-path depending on browser support when rendered CSS clip-path directly. If you look at the spec for clip-path it's listed as experimental.

 

But having said that .. when css clip-path is used with SVG that is a whole mother ball game. Whether via a URL identifier or on an inline SVG. You can get clip mask type effects that are cross browser. So I would recommend you use clip-path with SVG either as a URL identifier through your stylesheet or on inline SVG. Then you will get the results your after. You could even try and use and animate the SVG mask and or the clipPath element with the GSAP AttrPlugin and have cross browser compatibility, since SVG masks and clip-path have a wider range of browser support. Than trying to use css clip-path soley in your stylesheet and on a DOM element, instead of an SVG element.

 

SVG Mask element animated with AttrPlugin:

 

See the Pen OyarJK by jonathan (@jonathan) on CodePen

 

GSAP animating SVG clipPath elemwnt via a CSS clip-path URL identifier:

 

See the Pen LpVrPL by jonathan (@jonathan) on CodePen

 

:)

  • Like 1

Share this post


Link to post
Share on other sites

Thanks for your examples. ;-)

To be honest, I never thought the lack of stability of clip-path animations was in any way related to GSAP. In fact, I’ve already used the AttrPlugin to achieve such animations. What I’ve witnessed on some projects, however, is crazy unwanted behaviors from the browsers themselves. Your first pen, for instance, is pretty janky in desktop Safari on a retina display. I don't blame GSAP at all, I know this is on Safari.

 

As for Chrome, when I say I’ve witnessed crazy behaviors, I do mean crazy behaviors: hOqrejj.png

 

 

This, for instance, is how I saw Chrome handled a particular SVG-based clip-path animation a few months ago.  :shock:

The bits of content you see on the right-hand side, by the way, belonged to another tab I had just closed.

 

As you said, clip-path is still listed as experimental, and I came to the conclusion that it was for a good reason.

  • Like 1

Share this post


Link to post
Share on other sites

GSAP's Jack always adds great new fixes to handle the browser inconsistency and browser bugs.

 

Those pens were created awhile ago, so you could try those pens I posted above with the new 1.8.3 that just released, and see if anything resolves the jank. Also you can try testing out of codepen since codepens server can get pretty overloaded, and cause some weird behavior. But mostly that has to do with the browser support. But GreenSock's Jack creates alot of good polyfill stuff to make GSAP work even in browsers that dont render or animate like they should.

 

The dev Chrome team just got done fixing a major jitter bug that was introduced in Chrome 49, but now they fixed it.

 

In my experience WebKit based browsers like Chrome and Safari, have the most bugs when it comes to rendering, since they experiment alot with non standard behavior. Firefox will usually render better for most transformed elements, since it sticks close to the standards spec, and doesn't give you blurry text or images when scaled past a scale factor of 1.

 

Happy Tweening!

  • Like 1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 


  • Recently Browsing   0 members

    No registered users viewing this page.

×