Re: Animations in CSS or the DOM - what does the DOM community say?

On Apr 22, 2010, at 4:07 PM, Lars Gunther wrote:

> Hello all again!
> 
> I  have been first down with a stomach flu and then exceptionally busy.
> 
> But now I have taken some time to look into my proposal to move animations to the DOM now, and perhaps present my case in a more coherent way. Since I wanted to hear from the DOM community, I took it to my blog:
> 
> http://itpastorn.blogspot.com/2010/04/why-declarative-animation-should-be-in.html
> 
> I am pasting the most relevant part here:
> 
> ----------------------------
> OK, you are building a little library to animate stuff. What do you do? I suppose the following:
> 
>   1. First you capability detect support for declarative animation. That in itself would be easier if it was in the DOM, but it is at least doable now. But not in a neat fashion. Score one against having animations in CSS.
> 
>   2. If CSS-animation is indeed supported, you will wrap your animate function around className switches. Doable, but not neat.
> 
>   3. If CSS-animation is unsupported, you fall back to old school timed manipulation of the style attribute.
> 
>     * However, using the animation parameters from the CSS-file is a huge impracticality. You must find a way to read all CSS-files, parse them and interpret the cascade, the specificitivity of all animation rules and convert that information into timed logic. This is impractical, slow and CPU-draining and fragile.
> 
>     * The CSS Object Model (CSSOM) will not alleviate this problem. Browsers that need to parse the animation rules are the ones that neither implement animations, nor the corresponding CSSOM.
> 
> Alternatively, the author is required to re-specify the animation once again, now using a syntax for the fallback. We thus get code duplication, with all the error proneness and maintenance problems that follows from that approach. But it is the only approach currently available with reasonable results.
> 
> It can safely be said, that CSS-animations are not backwards compatible in any reasonable way. And we are going to need backwards compatible solutions for almost another decade or so.

I understand your arguments, but I don't think this is an either/or situation. I think having animations controlled by API is a good idea. But I don't think that makes CSS Animations a bad idea. I think the two can work together. In fact this happens with CSS all the time. Sometimes you use pure CSS (changing color on :hover), sometimes you use JS to change CSS classNames, and sometimes you access style directly and change individual properties. This is all very well defined in CSS. There is even API to use a Canvas node in the CSS background property. 

Some of this is CSSOM and some of it is DOM. I'm not sure which and I'm not sure it's important. I think the important thing is that there are many cases where animation is clearly style and can be controlled with purely declarative CSS, or by fiddling classNames in JS. I think that makes a good case for keeping the declarative approach for CSS Animations.

If your concern is that it's too hard today to use CSSOM to interact with animations (especially to create keyframes) then I agree. Hopefully Anne van Kesteren's CSSValue reworking will solve most or all of that problem.

As far as CSS animation syntax being "scary", I don't think it is any scarier than the rest of CSS which can be pretty arcane sometimes. But once you learn it, it makes pretty good sense.

As for your statement about "entering", "during" and "leaving" animations being confusing, I agree, which is why I am opposed to that idea. I do think we need to try to figure out an alternative way to trigger animations in the declarative content. But I also like the idea of a specific animation API to trigger them as well. I think the two can coexist nicely.

-----
~Chris
cmarrin@apple.com

Received on Thursday, 22 April 2010 23:58:35 UTC