Jump to content
GreenSock

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

Border radius not animating in Firefox

Recommended Posts

Hi @Wayrse and Welcome to the GreenSock Forum!

 

I was going to fork it but since its a Private pen so I cant. Please see below to see why it wasn't working.

 

Since you are using the new GSAP 3 syntax then you need to convert your gsap.to() tween to the following:

 

gsap.to() https://greensock.com/docs/v3/GSAP/gsap.to()

 

You have this with old GSAP 2 syntax with the duration as your second parameter:
 

// you have this using GSAP 2 syntax
test.to('.box', 1, {borderRadius: '10px'});

But it must be like this with the duration being one of the vars parameters for GSAP 3 syntax as the 2nd parameter of the new gsap.to() method:
 

// should be this using GSAP 3 syntax
test.to('.box', {borderRadius: '10px', duration: 1});

If you increased the duration you can see it better interpolate your border-radius, but even with 1 second you can see it animate even though its fast.

 

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

 

Happy Tweening!

:)

  • Like 3
Link to post
Share on other sites
7 minutes ago, Jonathan said:

it must be like this with the duration being one of the vars parameters for GSAP 3 syntax as teh 2nd paramter

That's not true - we recommend that people put the duration inside the vars parameter in GSAP 3 but they are allowed to put it as the second parameter if they want. Anyway, it's unrelated to this issue in Firefox. Your pen is still not working the same as other browsers for me at least (on Catalina).

  • Like 1
Link to post
Share on other sites
50 minutes ago, ZachSaucier said:
57 minutes ago, Jonathan said:

it must be like this with the duration being one of the vars parameters for GSAP 3 syntax as teh 2nd paramter

That's not true - we recommend that people put the duration inside the vars parameter in GSAP 3 but they are allowed to put it as the second parameter if they want. Anyway, it's unrelated to this issue in Firefox. Your pen is still not working the same as other browsers for me at least (on Catalina).


Your misreading my post  and whats in my code block. The 2nd parameter for GSAP 3 gsap.to() is the vars parameter. That is what i wrote and what's in my codepen.

 

I have the duration parameter in the vars, which is the 2nd parameter of the gsap.to() method!

 

I see it animating in latest Firefox Windows 10 with that change.

  • Like 2
Link to post
Share on other sites
35 minutes ago, Jonathan said:

I see it animating in latest Firefox Windows 10 with that change.

Yes, it animates. But it animates from 0px to 10px, not 50px to 10px.

  • Like 1
Link to post
Share on other sites

Well that is a different issue, but my statement on the gsap.to() syntax is correct and not, not true :)

  • Like 2
  • Haha 1
Link to post
Share on other sites

Okay, so the issue here is that even though you set border-radius in your CSS, getComputedStyle() in Firefox reports it as blank! I'd certainly consider that a bug in Firefox. 

 

In the next GSAP release, I work around this by sensing that condition and then pulling the value from borderTopLeftRadius. It seems to work well. Feel free to try it for yourself in the beta file: https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/gsap-latest-beta.min.js

 

Better? 

  • Like 3
Link to post
Share on other sites

For future readers: Note that if you need to animate only some of the border radiuses or animate the radiuses in different ways, you can do so by animating the specific properties like borderTopLeftRadius, borderBottomRightRadius, etc.

  • Like 3
Link to post
Share on other sites

@GreenSock @ZachSaucier @Jonathan Thank you all for taking the time to help!

 

I can confirm that the beta link fixes the issue and targeting borderTopLeftRadius etc. works as a workaround.

 

Thanks again!

  • Like 2
Link to post
Share on other sites

To stay at your Example for BorderRadius. 

 

A border radius Animation with different amount of digits will come up with an odd result  -> 

See the Pen YzPOQGG by themepunch (@themepunch) on CodePen

This worked well in the older GSAP (2.x).  Since we have a lot dynamic values, where we did not have any protection against this in earlier version, i thought  it worth to ask if you already  have a solution, or a gsap util, converter,  option for this ?

 

Thanks a lot and cheers !

 

 

 

Link to post
Share on other sites
2 hours ago, themepunch said:

A border radius Animation with different amount of digits will come up with an odd result

Why would you repeat the same 4 values like that? Using the shorthand and using 1 value that is then automatically used for all for is way more standard.

 

If you need control over each border radius, you should use individual properties like stated above:

See the Pen xxbaPbv?editors=0010 by GreenSock (@GreenSock) on CodePen

Link to post
Share on other sites
6 hours ago, ZachSaucier said:

Why would you repeat the same 4 values like that?

 


That should be a simple example without giving too many inputs. Let me make it more interesting than

See the Pen YzPOQGG by themepunch (@themepunch) on CodePen

As you can see, the interpretation is still wrong.  And to be honest i was hoping that there is a solution without the needs to set individual sides/corners etc. This issue is the same for borderWidth, padding, margin etc.   I think gsap should first check the calculated/computed style and animate from there and also convert short hand settings before animating.   It worked well in pre versions.  Maybe there is a better solution here ?

Link to post
Share on other sites
18 minutes ago, themepunch said:

As you can see, the interpretation is still wrong.

Right, this is what we were saying - if you're going to go through the trouble of setting different border radiuses for each corner then we think it's fair if you set the animations for them individually as well. We didn't think it was worth making everyone who uses GSAP pay the kilobytes to support looking for and setting each individual border radius automatically because most likely 99/100 people would never use that feature. Does that make sense?

  • Like 1
Link to post
Share on other sites
10 hours ago, ZachSaucier said:

 Does that make sense?

 

I totally understand that you try to keep things small and lite  weight.  Means i will  manage from now on to transform margin, padding, border-width and border-radius by their 4 different "values". Since this issue is for all those style attributes the same:   

See the Pen jOEvjgJ by themepunch (@themepunch) on CodePen

 

 

No Problemo ! Thanks for the feedback, and now i know what to do ! 

 

Wish you a great weekend ! 


 

  • Like 1
Link to post
Share on other sites

Alright, I spent some time digging into how to make this work without adding too much kb and I think I got it working relatively well for an extra 0.16kb gzipped. Here's a fork with the preview of the upcoming 3.1.0 release: 

See the Pen e9181f9f60e130bb5d77ee6e3935dff9?editors=0010 by GreenSock (@GreenSock) on CodePen

 

Better? 

 

Does everyone think it's worth adding? 

  • Like 1
Link to post
Share on other sites
1 hour ago, GreenSock said:

Does everyone think it's worth adding? 

 

Wow ! Cool ! I think it is great to have this on board.  I will definitely remove my workaround and use your solution if it is on board !  Brilliant Jack !  Really appreciate all your effort and hard work on this ! 

 

Thanks a lot and keep up the great work ! 

 

Cheers!!

  • Thanks 1
Link to post
Share on other sites

Alright, I had to add some extra code to accommodate getting the complex values with gsap.getProperty(), so it's up closer to 0.2kb gzipped. What that gets us:

  • Ability to smoothly handle borderRadius (including a workaround in Firefox due to it not reporting it properly), borderWidth, padding, and margin when they're complex values (at the start or end), like padding: "10px 4px" or padding: "10px 5px 15px 40px".
  • Ability to get those properties in complex format, like gsap.getProperty(".class", "borderRadius"), including the ability to define a unit, like gsap.getProperty(".class", "borderRadius", "%") even when they're complex like "10% 50% 40% 20%"

If we DON'T add this feature, then folks will always need to get/set each of these values via all four of their independent ones, like borderTopLeftRadius, borderTopRightRadius, borderBottomRightRadius, and borderBottomLeftRadius. Same for borderTopWidth, borderRightWidth, borderLeftWidth, borderBottomWidth, paddingTop, paddingRight, etc., etc. 

 

Probably not the end of the world but I imagine it'd be annoying to always type those out. And again, Firefox has a bug that causes it not to report the current borderRadius properly, so simply tweening to borderRadius:"50%", for example, will work in most browsers but not Firefox. This 0.2kb patch solves that in every browser that I'm aware of, though. So basically it's another layer of compatibility protection. 

 

I'm inclined to sacrifice to 0.2kb gzipped because GSAP is known as the gold standard in compatibility and ease-of-use. Any objections? 

  • Like 2
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

  • Recently Browsing   0 members

    No registered users viewing this page.

×