Why is a CSS solution better than a JavaScript solution?

Because it allows visual layer animation to be decoupled from behavioral programming and coupled with visual styles that it belongs to.

How it addresses the technical issues (when did the animation start, what is the value at any given time, what happens when I try to access a property of an element mid-way, how do I know that an element is being animated, when did it stop...)?

I don't see any problem at all. The animation starts when a CSS value changes. If you triggered that in Javascript, you know the time anyway. Value at any given time is exactly the same as now - a value "somewhere in the middle" of the animation in progress. You know when the element stops by adding the transformation duration to the start time.

All of these questions/problems are just a valid (and problematic) on current JS-only implementations of animation.

Ben said on November 02, 2007

Michael - Multiple backgrounds are in the CSS3 specification for sure, but to be honest I have no idea why they aren't supported anywhere else yet. Adding more markup to achieve the same effect defeats the point somewhat.

As for proprietary CSS - as long as it's legible and it works well, what's the problem? Would you rather have the CSS spec frozen because of the W3C's painfully slow progress? Do you mind waiting another 5 or so years for Microsoft to update Internet Explorer? Wouldn't it be grand to actually have good tools for development - like a proper grid based layout engine?

Oh wait, my bad. We already have that. It's called a table.

The only time proprietary markup is bad is when it's in place of functionality that should be built in. IE6 needs this kludge to render PNGs with proper transparency:


Trust Microsoft to come up with proprietary CSS that has their name in it.

Chris said on November 04, 2007

Animated CSS? sounds too much like <blink>blink</blink>

M??r said on November 04, 2007

Jonathan, my first impression with this idea was the same as yours. However, the more I think about it, the more appealing I find it.

Bear with me for a moment...

The common javascript syntax for most animation libraries involves passing concrete styling values as parameters (as illustrated by your own pseudocode examples above), which is obiously poor seperation of style and behaviour.

The best/cleanest seperation I've seen in javascript libraries, something like they implement in Mootools.fx.Morph demo, and , where the animation class' parameter is a CSS className. That way the CSS coder gets to decide the visuals.

That leaves only the decisions of a) transition-speed and b) 'easing'-effect in the hands of the Javascript programmer. However, most graphic designers I know would love to be able to tweak those parameters themselves, instead of having to go through the programmer all the time...

This is a gray area, and there will always be cases where a pure Javascript animation is more appropriate, but I think Apple's approach is a nicely logical step forward in the development of CSS.

Jermayn Parker said on November 04, 2007

I am only half an expert compared to most hear but they way I see it is that CSS should stay for STYLING (hint: Cascading Style Sheet) :?

Jeff Croft said on November 04, 2007

@Chris: What's wrong with blinking? The bling HTML element was a bad idea, because a presentational property should not be part of HTML, but it would be perfect for CSS. Granted, the property would be widely abused by lousy web designers, but that doesn't mean it's entirely useless. And, if it belongs, CSS is certainly the place where it should exist.

@Jermayn: So your assertion is that animation is not "styling?" I would beg to differ.

Ser said on November 06, 2007

How many users (%) of internet use Safari?

David Walsh said on November 07, 2007

I don't see this idea to be useful at all. It seems like a complete IE6 type of move -- if it's not something that will be supported by everyone (IE, 'fox, Opera), why create it? What value does it have? Sounds better suited for a javascript library to me.

Montoya said on November 09, 2007

Jeff is advocating blinking in CSS. Oy. Anything between a 2Hz and 60Hz frequency is *unhealthy* to look at! That's what blinking does!

I don't know how I feel about this animation support in Webkit, but I think it's stupid. Not that it's a horrible idea, just that there's so much support in CSS 3 to work on, and I want to at least see the standards-aware browsers working toward that, not thinking of random little "features" that are already achieved with Javascript.

Sorry, comments are closed for this post. If you have any further questions or comments, feel free to send them to me directly.