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

On Fri, Apr 23, 2010 at 6:09 AM, Lars Gunther <gunther@keryx.se> wrote:
> 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.

Because it applies to *all* CSS features, the argument is completely
non-specific.  It's not an argument for moving CSS animations to the
DOM, it's an argument for moving *CSS itself* to the DOM.  Since I
don't think that's what you meant, the argument isn't useful here.


>>> 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?

elem.style.animation = "foo 1s";

If this is difficult for an author, then writing *any* javascript is
difficult for them.


> 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 threw that sentence down in three seconds while composing the email.
 I'd write somewhat more clearly if doing a post intended to be widely
read, or be instructive to others.

That said, I expect that many authors *will* still be slightly
confused by the way animations work, as they'll expect them to
actually fire based on some notion of "state" that doesn't exist in
CSS.  We can't do anything about that, though - the system as it
stands is very good at *faking* being based on state, and anything
closer to a state-based system requires a fundamental and generally
damaging change to CSS.


> 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

Your two flows are in fact equivalent.  I'm not sure why you're
fetishizing the standard way of manipulating CSS via javascript.


>>>   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.

You don't need those various other abilities in order to parse out
@keyframes blocks.  The most you have to handle is multiple @keyframes
blocks with the same animation name, which is probably an author error
in the first place.

Even if you did, none of what you're listing are necessary abilities
for CSS parsers.  The job of a CSS parser is to parse CSS. That is,
take a chunk of text and turn it into some reasonably-constructed
object that represents the selectors and declarations and such.
Honoring the cascade is the job of the browser, and you can see the
results of that by querying getComputedStyle or currentStyle.  If you
point a parser at user-defined stylesheets or inline @style rules, it
should indeed parse them.


>>> 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?

I'm personally okay with the small amount of code duplication.
@keyframe blocks are generally small and easy to rewrite if necessary.
 As well, it's very simple to copy/paste and make minor modifications
to turn it into valid JSON (just insert quotes everywhere, a few
commas, and replace the semicolons with commas).  So a JS library that
took a JSON block formatted in that way (which would make a lot of
sense) would be easy to work with.

~TJ

Received on Friday, 23 April 2010 14:51:54 UTC