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

2010-04-23 01:28, Tab Atkins Jr. skrev:
> On Thu, Apr 22, 2010 at 4:07 PM, Lars Gunther<gunther@keryx.se>  wrote:
>>    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.
>
> This argument applies equally to *every* CSS feature.  It's easier to
> feature-test for *any* DOM property than it is to capability-test for
> *any* CSS property.

I don't see how that voids my argument.

>> 2. If CSS-animation is indeed supported, you will wrap your animate
>> function around className switches. Doable, but not neat.
>
> Why would you have to do this?  You can just manipulate the function
> of the animation property directly, like you would with anything else
> in scripted CSS manipulation.  CSS animations decide when to fire
> based on the value of the animation property changing, not based on
> classes changing (though class changes may cause the animation
> property's value to change, of course).

So how would you write a script that trigger the animation of a div when 
a user clicks a button? Could you write a piece of JavaScript that 
"manipulates the function of the animation property", please?

The "CSS animations decide when to fire..." sentence really shows why 
the current propsal is problematic. Show that sentence to 100 web 
developers and ask them to explain it in simple words. My guess is that 
90 % of them would fail.

I come back to this, since it is what developers are going to want:

* User does something - that causes an animation to begin.
* Significant event happens (like XHR data is received) - an animation 
begins.
* Etc.

In other words, I am not asking how this can be implemented in browsers 
or what syntax details should be. I am looking at work flow and use cases.

The flow is for any real world usage of animation:
1. Define animation
2. Set up event listener
3. When a DOM event occurs, run the animation.

For whatever reason can that not be reflected in the implementations? 
Why is this better?

1. Define animation
2. Set up event listener
3. When DOM event occurs, "change the animation property"
4. Run the animation

>>    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.
>
> This is true of *any* CSS property that is currently unsupported, and
> that you wish to emulate in script.  Dealing with @rules is somewhat
> more difficult than not doing so, but there are now JS CSS parsers
> (see http://glazman.org/JSCSSP/ ) that do the job for you.

CSS parsers will always be a significant slowdown, compared to having 
native functionality, even if they can be made completely reliable.

And will they honour the cascade? Will they parse all styles, including 
user defined and inline? A JavaScript CSS parser probably must do a 
significant amount of work to become usable in this context.

>> 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.
>
> Animations degrade more-or-less safely if you do them right.  They
> aren't significantly more difficult to fake in script than any other
> CSS property, especially given modern javascript tools.

That sentiment is what I would like the DOM-scripting community to 
confirm or deny. Are they OK with either parsing CSS or having code 
being duplicated?


-- 
Lars Gunther
http://keryx.se/
http://twitter.com/itpastorn/
http://itpastorn.blogspot.com/

Received on Friday, 23 April 2010 13:10:03 UTC