Currently I’m experimenting with jQuery (always being told prototype.js is evil). In my project I have to make quite some complex animations and I tried to detect if I can map them to the animate() syntax. Uh, and all hell broke loose. Here is my 24h experience:
- You can’t animate regular DOM properties, like image width/height, which is much more smooth than styles.
- It does not hold custom states, nor allows you to animate a virtual property ‘counter’ out of that you could folk all kinds of changes in the step-function. You HAVE TO animate a real css-style. Thus you fall back to your own timers and loose the easing-framework. Found it. But not optimal …
- You can not hold any states, if you stop an animation you will loose the information about the position of the animation between [0.0,1.0], and any other. You have to track that via the step-function and calculation through the ‘now’ time-stamp, OR you calculate the position directly on the modified CSS-value.
- Each modified style enters the effects-queue as a seperate function, or expressed differently: each property given to animate to change becomes an entire seperate animation!
- animate’s step function is called per step per property! Simultanious animation of multiple values becomes together with 4) almost impossible! A simple zoom function (width+height on content, left+top on parent relative to childs size-change) requires you to write approx. 50 lines!
- You can’t pause/resume animations (no states), you have to recalculate the position (see 3), recalculate how much time is missing and restart the animation.
- width/height animations force overflow hidden and display block. In 2010 I’d like to animate overflow visible and display inline-block too! Maybe even tables-cols if you don’t mind …
- You can’t define proxy-animations like “font-size = height / 10″, normally I’d say it should be possible to reference any animateable attribute/style.
- You can’t because of that also forget about the “font-size += delta-height” type.
- All calculations are done in floating point, as no browser supports sub-pixel accuracy you’l have horrible shift while zooming an image for example. The “zoom” effect anyway should be integral part of animate. Either way [left,left+width] are on a pixel-precision grid, if left becomes round down, left+width has to be round up (for zooming that is), of course trying to acount for this leads to headbanging on the keybord, because the animations are all seperate … and the step function is called per property …
Grr. Such a small function and so much issues.
