Re: [css-animations] When/how are keyframe values computed?

On Aug 8, 2014, at 10:33 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> If I'm understanding your notation correctly, I think option B is what
> we should be aiming for.

I agree it seems ideal and satisfies the principle of least surprise. This is also the one authors I've heard from say they prefer. (Though a solid half of that feedback derived from the related problem of non-animatable properties being ignored). Though keyframe rules have a funky selector authors don't think of them as special rules.

A seems broken to me. It seems no one does this.

C is not bad - clearly, it's what we've had for a bit - but it is inconsistent. I recall a video from Rachel Nabors (I think; can't locate it at the moment) which decomposed a larger animation into individual @keyframe rules. If you do that and one of your animating properties depends on another, you're going to have a bad time.

> 
> In general, I think we should strive for CSS Animations to have the
> same effect as just manually animating the same properties in JS;
> anything else seems likely to be confusing, and I don't think there's
> a decent a priori reason to do anything different (besides
> implementation concerns, perhaps).  

We heard some implementation/complexity concerns from dbaron; in particular, that this introduces some dependencies between animations. At least one implementation seems to be pulling it off though.


> This means that all properties
> should resolve against the "current value" of all other properties,
> which includes animated things.

Yes. Also, keep non-animatable properties, switch non-interpolable values at half-way etc. (I'm still not clear on why we wouldn't do the latter for transitions but that's another topic).

Received on Saturday, 9 August 2014 00:36:43 UTC