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

Re: [css-animations] What happens if a @keyframes rule is added after the fact?

From: Simon Fraser <smfr@me.com>
Date: Thu, 03 Jul 2014 09:18:03 -0700
Cc: "www-style@w3.org" <www-style@w3.org>
Message-id: <9479C9CA-349B-44B9-B63B-276D7B802A07@me.com>
To: Brian Birtles <bbirtles@mozilla.com>
On Jul 2, 2014, at 7:14 PM, Brian Birtles <bbirtles@mozilla.com> wrote:

> Hi,
> If I set "animation: doesntYetExist 10s" and, within 10s, add "@keyframes doesntYetExist { ... }" by script, what happens?
> a) The animation doesn't start
> b) The animation starts from the beginning
> c) The animation picks up from part-way through
> From my testing, IE does (a) and Chrome does (b). Current nightlies of Firefox do (c).
> This question also relates to whether dynamic changes to keyframes are honoured. David pointed out several years ago that the spec says values are snapshotted but WebKit doesn't do this (and hence nor does Gecko) and that there may be good reasons for allowing dynamic changes to keyframes.[1]
> I think (a) is more in keeping with the current wording of the spec but if we allow dynamic changes to keyframes then either (b) or (c) would be possible.

I think handling dynamic changes to the keyframes is tricky to do well; authors may expect some nice bridge between the current state given the old keyframes, and the new state given some possibly very different set of keyframes, which gets more complex with repeating and alternating.

It seems reasonable for me to consider the animation start time to be the time at which there first exists an animation-name value pointing to a set of keyframes. That implies b). However, wed have to consider whether a style change from an invalid set of keyframes to a valid set, or vice versa, would impact the animation.

c) makes me a little concerned about having to run animation logic for all elements with animation-name but no matching keyframes.

Received on Thursday, 3 July 2014 16:18:55 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:42 UTC