The next logical thing to think about with the animation capability is the idea of specifying the full state of every element during every time step. If this is done then we don’t have to worry about missing animation steps with important state changes. We can use the slider to advance to random points and we can increase the apparent speed of the animation by advancing by more than one step at a time. The downside is that more data is required to specify the full states during every animation step and it becomes more difficult to manage multiple streams of transitions that affect the same property of an element. The latter of those two issues seems to be the more problematic.
Let’s think about transitions that set the location of the left edge of an element. If there’s only one series of transitions then there’s no problem; we just set the position for every time step whether the element is in view or not. If there’s a second series of transitions that start after the first then we have to figure out how to use the one that applies and ensure that it works when the animation is moving forwards or backwards. We did some of that in a simple way by setting and clearing the bcChainFlag variable but now we need to do the right thing for potentially numerous transition effects for multiple elements.
For now I’m simply going to list all the issues I can think of.
- Multiple transition types may affect a single characteristic of an element. For example, the left position of an element could be affected by setting the left value directly or by applying the style.transform CSS properties translateX(x), translate(x,y), translate3d(x,y,z), matrix(n,n,n,n,n,n), and matrix3d(n,n,n,n,n,n,n,n,n,n,n,n,n,n,n,n). Depending on the parameters used, setting the display and opacity CSS values may also have the same (or different) effects. That said, there’s no formal need to support every possible transition type.
- We have to ask how much we should try to get our framework to bail the programmer out of possibly bad decisions or how much we should make the programmers sweat the details.
- To that end we could add more parameters to the specification of transitions to allow the programmer to control the range of steps that get filled in, by a transition–even when nothing is actually changing. Here I observe that the Greensock product I’m emulating (in a basic form) allows for a very simple specification of transitions and must be doing some of this in the background.
- Right now I’m writing out full JavaScript statements to be executed by the eval() command. In theory I could accomplish the same thing with a series of codes and a giant switch statement to handle the possibilities. The latter possibility occurs to me because it might be easier to write code to process numbers and parameters directly to figure out how to resolve conflicts between multiple transitions. That said, I feel like the statement/eval() approach makes more sense because the capabilities feel more modular and independent that way. I don’t know that’s true, I just feel it–for now.
- Also the same prioritizing can be accomplished by parsing out the raw text of the JavaScript statements. In either case I’d have to figure out some kind of hierarchy of effects to know how to resolve potential conflicts.
Basically, I just need to think about this more before moving ahead.