Bug 26150 - Negative values for animation-delay are ignored (treated as zero)
Summary: Negative values for animation-delay are ignored (treated as zero)
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac (Intel) OS X 10.5
: P3 Normal
Assignee: Simon Fraser (smfr)
URL: http://haravikk.com/#menu
Depends on:
Reported: 2009-06-02 16:20 PDT by Haravikk
Modified: 2009-12-11 13:03 PST (History)
6 users (show)

See Also:

Testcase (974 bytes, text/html)
2009-12-05 13:12 PST, Mihai Parparita
no flags Details
Patch v1 (4.65 KB, patch)
2009-12-08 01:43 PST, Shinichiro Hamaji
no flags Details | Formatted Diff | Diff
Patch v2 (6.66 KB, patch)
2009-12-09 00:51 PST, Shinichiro Hamaji
no flags Details | Formatted Diff | Diff
Revised patch (10.62 KB, patch)
2009-12-10 15:25 PST, Simon Fraser (smfr)
darin: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Haravikk 2009-06-02 16:20:11 PDT
According to the CSS Animation proposed specification (http://webkit.org/specs/CSSVisualEffects/CSSAnimation.html part 3.8), the animation-delay property, if set to a negative value, is supposed to start an element's animation immediately, but from an offset position within the animation.

For example, a value of -0.4s would create an animation that starts immediately, at 0.4 seconds until the end of the animation.

The provided URL demonstrates an intended use of this; notice that the segments of the "wheel" are pulsing in unison, however their starting-frames are supposed to be staggered so that the pulsing effect will move around the wheel, starting from "About" and then proceeding anti-clockwise to "Gallery" before starting again. This can be achieved by using equivalent positive delays, however 

It doesn't do to only half implement your own standards! =D

Otherwise great job though, the animation's are great.
Comment 1 Mihai Parparita 2009-12-05 13:12:28 PST
Created attachment 44350 [details]

Simplified testcase. The second square has a -webkit-animation-delay of -1s, but its spin is synchronized with the first, implying a delay of 0.
Comment 2 Shinichiro Hamaji 2009-12-08 01:43:06 PST
Created attachment 44463 [details]
Patch v1
Comment 3 WebKit Review Bot 2009-12-08 01:47:04 PST
style-queue ran check-webkit-style on attachment 44463 [details] without any errors.
Comment 4 Haravikk 2009-12-08 04:40:12 PST
It's great to see progress on this, and to think the solution can be so small and elegant, thanks Mihai Parparita and Shinichiro Hamaji!
Comment 5 Simon Fraser (smfr) 2009-12-08 08:22:54 PST
Comment on attachment 44463 [details]
Patch v1

This patch works well for software-animated properties like 'left', but does not work for properties animated via GraphicsLayerCA, like -webkit-transform and opacity (you'll have to be on Mac OS X to test these).
Comment 6 Shinichiro Hamaji 2009-12-09 00:51:18 PST
Created attachment 44517 [details]
Patch v2
Comment 7 Shinichiro Hamaji 2009-12-09 00:54:14 PST
Thanks for the review! I added a similar fix for hardware animation
case and added a testcase where GraphicsLayerCA is used on Leopard.

Could you take a look again?
Comment 8 Simon Fraser (smfr) 2009-12-10 15:25:00 PST
Created attachment 44642 [details]
Revised patch

This patch is on top of the patch in bug 32387, which touches the same code.
It also adds a testcase for transitions with negative delay, which are affected by this change, and fixes the language in some comments.
Comment 9 Shinichiro Hamaji 2009-12-10 19:47:42 PST
Thanks for improving the patch! This looks great after you changed the semantics of setAnimationOnLayer.
Comment 10 Simon Fraser (smfr) 2009-12-11 13:03:39 PST