transformOrder added

[samuelhorwitz]

Solution for #197. There is now an options argument called transformOrder which is by default an empty array. It can be filled with an ordered list of transform properties as strings. It will sort the transformCache before applying it.

[julianshapiro]

Good stuff, Samuel! Anyone else have thoughts on this?

[Rycochet]

Nice idea - however my one thought is this - we have several other things (background-image and box-shadow spring to mind) - would it be possible to extend this idea, or make an API type idea, to allow animating a multiple list of those too? Can't think of anything off the top of my head, but I think that this might actually be a simple enough idea to start something :-D

[samuelhorwitz]

I probably won't have time to generalize it as this was me hotfixing something downstream for my job, but if I had to speculate for a general solution, it would be something like:

"cssOrder": {
    "transform": ["translateX", "scaleX"],
    "otherCssProperty": ["foo", "bar"]
}

That being said, the two examples you gave of background-image and box-shadow aren't properties that one would animate necessarily in this way. I'm not super familiar with Velocity but the issue at hand is that Velocity abstracts transform CSS into specific transform types like scaleX and translateX and rotate which then have to be merged back into a CSS transform string. This might not be a generalizable issue unless other similarly broken-out and remerged CSS properties exist in Velocity.

[Rycochet]

I was thinking more along the lines of animating either colours or values, so a linear gradient background could have the colour stops change or move etc - more of an idea that this gives a start to getting those animated without having to manually code everything.

Possibly something like -

$(el).velocity({
   backgroundImage: [[null, null, null, 0.8, "40%", etc], "linear-gradient(to bottom, rgba(1,2,3,0.4) 50%, rgba(6,7,8,0.9) 100%)"]

• so basically the array points at the nth number in the string to be replaced... And no, that's not a good example, but it's where my head went ;-)

Back on topic - I think this solution works well for transforms, and would hit on almost exactly half of the issues people have with it ;-)

[samuelhorwitz]

Ah I see what you mean :) I'm probably not gonna be able to find time to work on any solutions like that but I get what you are saying. For now, I think just supporting the transforms should be good because there is an explicit shortcoming with transforms being order-dependent but it could probably be broken out if the other functionality ends up implemented as well

[konistehrad]

I'm going to +1 this issue. In particular, we need translate and scale to reliably apply in that order, and this patch would allow that.

[clessg]

+1

[exophunk]

+1. No way to reverse animate transforms because the rotates and translates get applied randomly

[Rycochet]

Got a probable alternative to this in #697 - comments would be useful