Jump to content


css custom properties/variables

Recommended Posts

i attempted to upgrade gsap version at work and implement a tween of some css variables and immediately found an problem in chrome version 49 which i have personally already bumped into, and not sure what other browsers this could also branch to. to be clear, this is a problem in chrome, but the workaround is easy enough you might want to incorporate it into gsap. in chrome 49 when calling `setProperty` on a css variable that is already declared, rather than replacing the old value, it is added to the element. so throughout the course of a tween, a css variable is then defined on an element many times, which the latest one is always the overriding winner, but there seems to be some performance hits associated with this as well as timing effected. teh known workaround is to call `removeProperty` before calling `setProperty` again. go ahead and try out the jsfiddle in chrome 49 and watch the inspected markup as you click around.

See the Pen by 28mx1pm0 (@28mx1pm0) on CodePen

Link to comment
Share on other sites

Hm, did you mean Chrome 59?


And are you saying that you see the --border-color value being applied to the inline style multiple times (like, --border-color:rgb(...); --border-color:rgb(...)" at once? (I didn't see that) Or are you just saying that you don't think it should be showing up inline at all? 


It does seem like the safest, most broadly-supported way to handle CSS variables is to place them at the :root (on the html element). Is there a reason you wanted to avoid that? 


It'd be a bummer to have to make an extra function call to removeProperty() on every tick (performance-wise). And you mentioned that you noticed a performance penalty with the current behavior - would you mind showing me how to reproduce that? How did you test it? What exactly gave you the impression that performance suffered? (I'm not disagreeing - I'm just trying to see what you're seeing). 


Thanks Dane! 

  • Like 1
Link to comment
Share on other sites

49, not 59. at my job we ship our product in chromium v49, and yes, applied multiple times like you said at first. the reason for not applying the tweened css variable at the root is that i want it scoped to each element. as far as the performance/timing issues, its more difficult to see in my jsfiddle, but i was able to see some lagging when clicking around a bunch. in implementation on the project it was much more obvious because of the weight of the application. i wouldn't suggest always calling `removeProperty`, but on the first css variable tween it could probably be determined if it were necessary and then called or not called from then on.

Link to comment
Share on other sites

Hm, that's a tough one. Since it seems to already be fixed in more recent versions of Chrome, what you're asking would require adding probably 3x more code than this feature already requires, just to get better performance in an outdated version of an evergreen browser. See what I mean? I suppose that you could just leverage a ModifierPlugin tween to run your removeProperty() first. Kinda like: 


TweenLite.to("#parent", 3, {"--color":"blue",
    modifiers: {"--color":function(value, target) {
            return value;


See https://greensock.com/docs/Plugins/ModifiersPlugin to learn more about ModifiersPlugin. 


Might that suffice? 

  • Like 2
Link to comment
Share on other sites

  • 3 weeks later...

yes, this does this trick! but when implementing i noticed that on a .fromTo tween that i need the modifier on both objects passed in. is that expected? and if so, why?

Link to comment
Share on other sites

That's expected as the from vars becomes it's own zero duration tween, so you need to modify that tween too.

  • Like 4
Link to comment
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.