W3C home > Mailing lists > Public > www-style@w3.org > June 2013

Re: [css-anims] Play-state interaction with delay update

From: Henrik Andersson <henke@henke37.cjb.net>
Date: Sun, 09 Jun 2013 20:53:27 +0200
Message-ID: <51B4CF27.9050401@henke37.cjb.net>
To: "Tab Atkins Jr." <jackalmage@gmail.com>, François REMY <francois.remy.dev@outlook.com>
CC: CSS WG <www-style@w3.org>, Animations W3C WG <public-fx@w3.org>
Tab Atkins Jr. skriver:
> On Mon, Jun 10, 2013 at 1:30 AM, François REMY
> <francois.remy.dev@outlook.com> wrote:
>> Hi everybody,
>> I’ve been thinking about a usecase today where I wanted an animation to stop
>> playing while still being able to “seek” inside the animation timeline.
>> I was hoping to use “animation-play-state: paused” and then update the value
>> of “animation-delay” to seek into the animation but it doesn’t seem to work
>> as I expected (the value of the animations properties are kept frozen even
>> after the delay has been changed).
>> If we think in terms of Web Animations, marking the animation as paused is
>> equal to setting its playback rate to 0 temporarily, but that should not
>> prevent seek operations to work.
>> What do you think of it? Should that be changed? Or should it just be
>> clarified that changing the animation delay does not cause the animation to
>> be recomputed? In all other cases, changing the animation delay 'restart'
>> the animation from scratch (at the animation-delay time). My belief was that
>> it would still do the same when paused, except that the state after the
>> restart would be paused.
> I find your assumption reasonable, that pausing the animation is
> effectively just setting its playback rate to 0, which means you can
> still seek within it.
> However, there may be deeper reasons why the animation is best treated
> as "frozen" instead.  Shane/Brian/etc., any comments?
> ~TJ

If nothing else it makes it easier to detect that no changes are
occurring and that no rendering will need to be done because of it.
Received on Sunday, 9 June 2013 18:54:03 UTC

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