W3C home > Mailing lists > Public > www-style@w3.org > August 2014

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

From: Sylvain Galineau <galineau@adobe.com>
Date: Sat, 9 Aug 2014 00:35:54 +0000
To: Tab Atkins Jr. <jackalmage@gmail.com>
CC: "<www-style@w3.org>" <www-style@w3.org>
Message-ID: <7A1C6312-D80A-4785-948E-BA076A852352@adobe.com>

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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:45 UTC