Monday, June 14th, 2010

animateWithCSS: Aza’s jQuery Plugin

Category: Animation, CSS


  1. // Makes all paragraph elements grow a border and then atrophy away.
  2. $("p").animateWithCSS(
  3.   {border: "5px solid #555"}, // CSS properties to animate
  4.   1000,                       // Duration in ms
  5.   "cubic-bezier",        // The timing function
  6.   function() {              // Callback
  7.     $("p").animateWithCSS({border: "0px"}, 350);
  8.   }
  9. );

Above is an example of Aza Raskin’s jQuery plugin that sits on top fo CSS transforms.

The code renders this:

What is maybe even more interesting, is the critique into CSS transitions:

Better timing functions. While using a cubic bezier curve is clever—it packs a lot of variation into just four numbers—it isn’t enough. While I was able to create a basic bounce animation, not only does the spec explicitly disallow it, but I can’t control even the basic parameters of the bounce (like how fast it returns). As John Resig mentioned in a blog post, it would be nice to supply a custom Javascript timing function (although this might break the ability to do hardware acceleration). A more CSS-like solution might be to allow authors to provide an arbitrary number of control points for a series of linked quadratic or cubic bezier curves (and to not restrict the y-axis points to the 0 to 1 range). That would enable fine-grained control of timing without requiring Javascript.

Ability to layer two animations on top of each other. If I’ve started an animation moving an element to the left, and half-way through want to start animating its opacity at a different rate, things get complicated very quickly. And by complicated, I mean impossible.

Ability to register an on step handler. We can currently register a “transitionend” event handler. I’d like to be able to do the same for “transitionstep”. This would make CSS Transitions potentially much more versatile—and allow frameworks to keep innovating on top of the transitions base instead of reverting to pure Javascript animation.

Posted by Dion Almaer at 5:36 pm

2.9 rating from 15 votes


Comments feed TrackBack URI

Don’t get me wrong, I like all the new stuff in CSS3. But it really feels like it’s getting to be an unplanned, unscalable mess. Because CSS is shallow, it must get wider and wider in order to do more. What I mean is, each property does something very specific, so adding more features means adding more specific properties. How much longer do you suppose this can go on?

Besides that, CSS was stupidly made to not play well with JS from the beginning and is only getting worse. For example, I have an element with multiple backgrounds. I want to change or remove one background with JS without affecting the others. It is not immediately obvious how to do this or if it is really possible.

JS and CSS need to get more friendly with one another, not less. And both need to get deeper, not wider. The current and future states of JS are looking good. CSS… not so much. I think it’s about time to throw the whole thing out and start over with something much more flexible.

Oh, and the ‘X’ in ‘AJAX’ is for ‘XML’ but I don’t know what the ‘X’ in ‘Ajax’ is for.

Comment by okonomiyaki3000 — June 14, 2010

‘Advanced JAvascript eXperience’.

I disagree with just about everything you’ve said here re: CSS and Javascript.

CSS should be wide, not deep, because of the cascading nature of stylesheets. What I have a problem with as far as CSS3 is the very fractured nature of which browser supports which features now, and which are coming down the pipe. (This also applies to HTML5). The support for the next generation of markup is scattershot and confounding.

The real problem isn’t CSS3, it’s namespaced CSS properties (-moz-blah, -webkit-blah) that are implementing their own version of properties that should simply be rolled into CSS. Surely the standards spec could be more granular and progressively modified than it is currently.

Comment by elsewares — June 14, 2010

Complete agree with you elsewares. The problem is the standard, or the fact that there isn’t one with CSS and HTML5. And the worrying thing is specific vendors keep adding new namespaced properties to their CSS without it being in the spec, which therefore means it could very well only ever be supported by one browser.

It seems that, just as we are starting to move away from the woes of IE6, new ‘challenges’ are there to test us as web developers. Challenges that wouldn’t be a problem if they weren’t rushed out.

Saying that, I do love some of the new stuff in CSS3!

Comment by ahallicks — June 15, 2010

CSS is meant to be a presentation layer, simple transition effects in css do not change this. For example making the font size increase and change colour for hovering over a menu item.

But if animations need to be stacked and give feedback to scripts then everything starts to become very muddled.

SMIL + SVG is much better suited for complex animations on a web page. Browser support obviously is a problem, but the same situation exists with css transitions.

A nice example below shows an animated train track and works in browsers apart from IE.

Comment by McDaid — June 15, 2010

Why would anyone want to do CSS animations with JavaScript?

Comment by JSkid — June 15, 2010

@elsewares: The reason for -moz-blah and -webkit-blah is that the W3C moves slower than a sloth watching molasses when it comes to adopting new standards. I mean is CSS3 even official yet? I think half the specs are still in the “we’re thinking about it” stage.
So browser makers that want to push new stuff out have to resort to those prefixes until the new standard is finalized.
Basically, my point is, blame the W3C, and Canada, for good measure. :)

@JSkid: At least to reasons I can think of
1) JS gives you more control over it, and it’s dynamic – you can adjust animations on the fly without predefining twenty different styles.
2) To use the same JS code for animations across browsers but have it smartly use either JS animations or CSS animations depending on browser.

Comment by iliad — June 15, 2010

@iliad: to=two (I failed the internets! Doh!)

Comment by iliad — June 15, 2010

@elsewares: if you don’t like unofficial, vendor prefixed css, don’t use it. Problem solved. I’ve heard several people bitch about this and, frankly, it’s an idiotic complaint. Anything with a vendor prefix is not finalized and support is basically included as a preview. There are two alternatives to this:
1) No preview. You’ll get CSS3 when the spec is official and not a thing before then. No experimenting until then.
2) The spec isn’t even done but we’ll go ahead and use the standard property names without prefixes. You can start to use CSS3 now but good luck getting things to work in more than one engine.

CSS is supposed to be wide and not deep because of the cascading blah blah blah. Well, I guess either you don’t know what I mean by wide and deep or I have missed some implication of the cascade. Either is equally likely. But in case I’m missing something and ‘cascading’ really is incompatible with whatever I was talking about… then throw out the stupid cascade. It causes more problems than it solves anyway. If CSS had any sensible kind of inheritance, you wouldn’t miss cascading in the least.

Anyway, my point was, extending CSS by constantly making it wider rather than deeper is a disaster in the long run. Rounded corners were popular so not it’s part of CSS. Drop shadows were popular so now they’re in CSS. Gradients were popular so now they’re in CSS. I’m glad all of these things are in CSS but where does it end? Just keep adding more properties for anything that becomes popular in web design? Wouldn’t it be better if there was flexible language for describing things that the creators of the language didn’t already imagine? Sure it would be more complicated and harder to learn but who cares? Learning is good for your brain.

Comment by okonomiyaki3000 — June 15, 2010

@okonomiyaki3000 – I also feel that the transitions deal with CSS3 is not a good thing. I feel that any reaction to interaction should not be part of CSS. CSS should just be for plain presentation as to prevent it from becoming a huge mess, which it is on track for. If CSS goes down this path it will eventually be a basic programming language. To keep things simple it should stay like this: HTML = markup, CSS = presentation, Javascript = interaction. Clearly defined roles that avoids confusion.
@illiad – I agree about the vendor prefixes, they are a rather annoying thing that I feel will slow adoption. If they weren’t used and we could write one line of CSS instead of two or three we might be more apt to use them. But then again, since the vendors can’t agree on many things (which slows things down even more) the vendor specific prefixes are a necessary evil.

Comment by travisalmand — June 15, 2010

… And the Mootools world got Fx.Tween.CSS3 ! ;o)

Comment by SunboX — June 15, 2010

@okonomiyaki3000: I agree with most of what you’re saying, but not about AJAX. It’s acceptable English usage to use an initial cap for pronounceable abbreviations (acronyms), so HTML and CSS, but Ajax.

Comment by Skilldrick — June 16, 2010

Leave a comment

You must be logged in to post a comment.