Bug report: background linear-gradient

[Malnurtured]

There appears to be an issue in GSAP 3 with tweening the background shorthand property when using a linear-gradient, as demonstrated in the CodePen.

 

Specifying just a linear-gradient  works correctly in Chrome and Safari, but not in Firefox, where it doesn't animate at all.

gsap.to('selector', {
  background: 'linear-gradient(90deg, rgb(255, 0, 0) 10%, rgb(0, 255, 0) 90%)',

  duration: 2
});

 

Specifying a background color paired with a linear-gradient works correctly in Firefox but not in Chrome or Safari, where it incorrectly animates the linear-gradient rotation in addition to the color.

gsap.to('selector', {
  background: 'rgba(0, 0, 0, 0) linear-gradient(90deg, rgb(255, 0, 0) 10%, rgb(0, 255, 0) 90%)',

  duration: 2
});

 

This can be worked around by instead tweening backgroundImage, which works correctly in all browsers, but it would be nice to be able to use the shorthand property.

gsap.to('selector', {
  backgroundImage: 'linear-gradient(90deg, rgb(255, 0, 0) 10%, rgb(0, 255, 0) 90%)',

  duration: 2
});

See the Pen MWwyJLe by malnurtured (@malnurtured) on CodePen

[GreenSock]

I wouldn't really consider this a bug - it's just a limitation of shorthand properties like this because they can be formatted in many different ways and it'd be too clunky/cumbersome to bake in a parser that'd take every option into consideration. Let me explain how it works internally...

 

GSAP needs a starting value and an ending value to interpolate between. That's easy when it's simple numbers, but when you introduce complex strings that have numbers, characters, and colors, it must convert the colors into RGBA or HSLA (so that there are actual numbers to interpolate), then isolate the parts of the strings that are numbers (in order) and then interpolate between those. So the first number in the starting string gets matched with the first number in the ending string, and so on. 

To get the starting value(s), GSAP must get those from the browser via getComputedStyle() and here's the key problem in your scenario - Firefox reports the current background value in a format like "rgba(0, 0, 0, 0) linear-gradient(90deg, rgb(255, 0, 0) 10%, rgb(0, 0, 0) 90%) repeat scroll 0% 0%" whereas your ending value is something like "linear-gradient(90deg, rgb(0, 0, 0) 10%, rgb(0, 255, 0) 90%)" See the issue? They're completely different formats, and in different orders. Other browsers, like Chrome, report the current value in your demo as something like "linear-gradient(90deg, rgb(255, 0, 0) 10%, rgb(0, 0, 0) 90%)" so it matches the format you're feeding in. The values line up.

 

Sure, I could add a bunch of extra code to GSAP to try to do custom parsing of funky values like this, but that'd impose a kb cost on everyone even though almost nobody really NEEDS to animate backgrounds like this. Those who want to animate a linear gradient like this can do so via the backgroundImage property as you pointed out. Zero extra kb, and frankly it strikes me as much cleaner too because there's no ambiguity. 

 

Make sense?