Extend gsap properties

[Green-Alpha]

Hello,

 

Is it possible to extend gsap properties ? I mean we set individual properties "translate, scale..." and then set CSS transform to translate/scale... on element.

 

I think gsap doesnt handle properties like blur, brightness because of old IE have a specific behavior with CSS filter property, right ? Anyway I have to find a way to do it quicker than  :

 

gsap.to({
	blur : 0
}, {
	duration : 1,
	blur : 10,
	onUpdate : function() {
		elem.style.filter = [...];
	}
});

 

Like :

 

gsap.to(elem, {
  duration : 1,
  blur : 5,
  brightness : 2
});

 

What is the best way to achieve this ? or more generally how to extend properties ?

 

Thanks !

[ZachSaucier]

Hey Green-Alpha. If you're going to be using this relatively often that's a good reason to write your own GSAP plugin! That allows you to write custom properties. 

 

In fact, our example plugin is in fact a blur plugin  Check it out:

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

[Green-Alpha]

Where is located the link targeting this example ? because I searched and found many things for blur but not this.

 

Thank you for this fast reply !

[GreenSock]

We even created a video about this: 

 

[ZachSaucier]

10 minutes ago, Green-Alpha said:

Where is located the link targeting this example ? because I searched and found many things for blur but not this.

I just posted the link a couple more places so hopefully people will be able to find it more easily.

[OSUblake]

Updating it yourself is probably the best option. You have to remember that the order a filter function is applied can change the result.

 

What goes first, hue or drop shadow? 

 

gsap.to(elem, {
  hueRotate : 90,
  dropShadow : "16px 16px 10px blue"
});

 

Changing the order will give you completely different results.

 

See the Pen e487e067332729dbc229d85db9c336a9 by osublake (@osublake) on CodePen

 

 

And a filter function can be used more than once.

filter: hue-rotate(90deg) drop-shadow(16px 16px 10px blue) hue-rotate(45deg);

 

There is no way to specify that using an object syntax.

gsap.to(elem, {
  hueRotate: 90,
  dropShadow: "16px 16px 10px blue",
  hueRoate: 45 // NOPE!
});

 

[ZachSaucier]

34 minutes ago, OSUblake said:

You have to remember that the order a filter function is applied can change the result. ... And a filter function can be used more than once. There is no way to specify that using an object syntax.

Couldn't you build a plugin to support both of these features?

[Green-Alpha]

Thank you for this replies

 

@OSUblake Houston, we got a problem ^^ I keep it in mind, for now I will go with simple filters, because i parse filters and get an object like :

 

{
  dropShadow : ['0 0 10px #000'],
  blur : [10]
}

So this will be "inline", but i don't think i will have to set this property with specific order.

[OSUblake]

29 minutes ago, ZachSaucier said:

Couldn't you build a plugin to support both of these features?

 

To fully support everything would be nearly impossible because the order can change the final result. There isn't a "good" way to order the functions to always get a consistent result like there is with transforms. And using the same function more than once would be nearly impossible to create rules for. That's one of the reasons gsap can't do tweens that would result in a transform like this using x and rotation properties. 

 

transform: translateX(100px) rotate(45deg) translateX(300px);

 

47 minutes ago, Green-Alpha said:

So this will be "inline", but i don't think i will have to set this property with specific order.

 

The order shouldn't matter much for that example, and it's easy enough to just use strings.

 

gsap.to(elem, {
  filter: "drop-shadow(0px 0px 10px #000000) blur(10px)"
});

 

See the Pen 0f162c31802261419785e14320b6f8d6 by osublake (@osublake) on CodePen

 

 

[OSUblake]

Actually, I think the drop shadow isn't working correctly in my example above. I thought @GreenSock fixed the color problem in this thread.

 

 

 

 

[Green-Alpha]

I agree with what you said @OSUblake but this mean 0 support for blur or any other simple effect that we can apply frequently.

 

With this point of view we will never see

 

gsap.to(elem, {
  blur : 10
})

on gsap, and this mean ignore an important stuff because the implementation can't fit with all case of use, and use "tricks" to achieve the simple goal.

 

I ask myself : when and how many time i will use the filters with complex structure ? Probably 0.1% of time, and when this case will happen, i will easily switch to fallback by specifying the filter manually.

 

But I really understand that you want keep the fit all logic !

[OSUblake]

You can do most filters just like you would in CSS. 

 

gsap.to(elem, {
  filter: "blur(10px)"
});

 

The problem with my demo above is how Chrome reports the color value in drop shadows. It reports the color first, which messes up the string interpolation.

drop-shadow(rgb(0,0,0) 0px 0px 0px)

 

 

[OSUblake]

43 minutes ago, Green-Alpha said:

I ask myself : when and how many time i will use the filters with complex structure ? Probably 0.1% of time, and when this case will happen, i will easily switch to fallback by specifying the filter manually.

 

Maybe @GreenSock can chime on this as he is the decision maker. I just think trying to do filters similar to the way gsap does transforms might be pretty hard. 

[Green-Alpha]

? i just say what i'm thinking...i was thinking a forum is a way to talk about things...

Anyway thanks for replies subject closed.

[OSUblake]

6 hours ago, Green-Alpha said:

? i just say what i'm thinking...i was thinking a forum is a way to talk about things...

 

Yes, and that's a good thing. Keep it coming! Feedback like this is how gsap improves. 

 

I wasn't being critical of your idea, just critical of how to implement it. The PixiPlugin handles filters kind of like you want, but it works with a smaller set of filter functions than what is provided by CSS. 

 

See the Pen OgQJqV by GreenSock (@GreenSock) on CodePen

 

With CSS filters, there is a crazy amount of permutations. For example, you can combine css and svg filters.

.div {
  filter: url(#svgFilter) blur(10px);
}

 

But the biggest problem I currently see with CSS filters is how Chrome incorrectly reports the color in drop shadow filters. But perhaps a "css filter plugin" could fix that issue.

[GreenSock]

21 hours ago, OSUblake said:

Actually, I think the drop shadow isn't working correctly in my example above. I thought @GreenSock fixed the color problem in this thread.

Yep, I did for boxShadow but the reason it's not working for filter is because "drop-shadow(...)" is formatted differently - the wrapper makes it a lot harder algorithm-wise. 

 

I spent time trying to craft some code that'll sense when there's a mis-match in the order of numbers/colors between the starting and ending complex strings, and adjust them accordingly. It's not a simple thing; it'd cost close to 0.2kb gzipped. Do ya'all think it's worth adding? 

 

This improvement would affect all complex string parsing, not just filter:drop-shadow() and boxShadow. That means it'll work with the gsap.utils.interpolate() method too:

var interp = gsap.utils.interpolate(
  "drop-shadow(rgba(255, 0, 0, 1) 0px 2px 2px) blur(0px)", 
  "drop-shadow(0px 0px 10px rgba(0, 0, 255, 1)) blur(10px)"
);

console.log(interp(0.5)); // drop-shadow(0px 1px 6px rgba(128,0,128,1)) blur(5px)

I put it into the preview of the upcoming release: https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/gsap-latest-beta.min.js

 

Does that work well for you? I'd appreciate it if you could hammer on it and see if you can break it because it required an overhaul of some of the color-parsing code in the guts of GSAP. Seems to work great for me thus far.

 

I saw your suggestion, @OSUblake about maybe adding this kind of thing via a plugin, but that didn't seem to fit because:

• Doing it at a very low-level in GSAP allows it to affect everything (interpolate(), other plugins, etc.) 
• It could be accomplished with fewer kb by wiring it into the core (we can skip the plugin wrapper around it)
• Of course I like saving folks the hassle of loading another plugin. If we were gonna try to do a full-blown CSSFilterPlugin that handles the order of multi-filter scenarios, etc., that'd be a better fit for a plugin but I'm not sure it's really that necessary since this patch/improvement would empower people to do most of what they need with only the core. 

I lean toward adding this despite the kb. I just like fighting for every little kb we can save and ensure that it's worthwhile to the community. Since this could save folks hassle in various situations with complex strings and cause things to "just work" (a branding promise I like delivering on), it's probably worth the 0.2kb gzipped. Agreed? I'm pretty confident no other animation engine does this kind of thing, so it's another nice differentiator.