web-animations / web-animations-js-legacy Goto Github PK

replace with Object get or with defineProperty.

Given:

anim1 = new Animation(/* ... */);
anim = new SeqGroup([anim1]);
anim.reverse();
anim.pause();

Expected result: anim is paused and if anim.play() is called, the group will play in reverse.
Actual result: the group does not play, but if anim.play() is called again, it plays as expected.

See: https://github.com/sorvell/web-animations-js/blob/master/smoketests/test-reverse-group.html

In WebKit, the 'transform' property applies to SVG elements. In Firefox it does not. Instead, Firefox SVG elements accept a 'transform' attribute value.

We'll need to detect this feature so that we can decide whether SVG 'transform' animations should be applied through style or through the 'transform' attribute.

Still to do:

• promote 2d animations to 3d animations when interpolating from 2d to 3d or vice versa
• implement special rules for 3d rotation
• clarify whether rotateZ should collapse to rotate in 2D case
• clarify whether rotateX-Z should collapse to rotate3d
• implement special rules for matrix interpolation
• implement special rules for perspective interpolation

See a3d2fff

TimedItem is no longer seekable, so has no concept of a time drift.

We decided to remove this as it's just syntactic sugar for 'Player.source = null;'. See agenda item 5 of https://etherpad.mozilla.org/ep/pad/view/ro.gsZ7DnSJB9X/latest

We need to remove this from both the spec and polyfill.

The following doesn't animate smoothly:

new Animation(target, {left: ['0','500px']}, 1);

But this does:

new Animation(target, {left: ['0px','500px']}, 1);

The polyfill currently provides TimedItem.changePlaybackRate(), which updates TimedItem.timing.playbackRate and seeks so as to preserve the current playback position. The method is not in the spec.

We should decide how we want to expose this functionality and then make sure the spec and polyfill match up.

We probably can't do this until we've resolved how to expose supplied and calculates timing parameters. See web-animations/web-animations-js#134

(see shans/web-anim-js#28)

The spec [1] states that Player.currentTime is zero for a Player whose Timeline is not started. Given this, when assigning to Player.currentTime while in this state, we update the time drift but continue to return zero for currentTime. The time drift manifests itself once the Timeline starts.

However, the algorithm for pausing means that if the TimedItem is paused and unpaused before the Timeline starts, any time drift calculated above will be lost and reset to zero. This is odd, as pausing and unpausing at any other time will leave the currentTime unaltered.

We should decide if this behaviour is desired. If so, it probably should be mentioned explicitly in the spec. Either way, we should update the polyfill if required and add a testcase.

[1] https://dvcs.w3.org/hg/FXTF/raw-file/default/web-anim/index.html#the-current-time-of-a-player

new Animation(undefined, {}, 2)

-> Uncaught TypeError: Cannot call method 'sample' of null

Given:

anim1 = new Animation(/* ... */);
anim1.pause();
anim = new SeqGroup([anim1]);

Expected result: anim1 will play when anim is played.
Actual result: anim1 never appears to play.

See smoke test here: https://github.com/sorvell/web-animations-js/blob/master/smoketests/test-pause-then-group.html

new Animation(target,
{'-webkit-transform': ['translate3d(0,0,0)', 'translate3d(100%,0,0)'],
1
);

The above animation fails on Chrome 25 but works on Canary. I notice that -webkit-calc is used to generate intermediate values for this animation. This appears not to be supported.

This problem is also evident in test-transform-units.html which fails silently. Notice, for example, the top row left and right squares. These do not animate properly but do have the correct end state.

new Animation(target, {transform:'translate3d(0,100%,0)'}, 0.3)
new Animation(target, {opacity: '0'}, 0.3)

I want to animate the target from the current values. The first animation throws an exception but but the second animation works as expected.

e.g. at the moment we need to do:

new Animation(target, { opacity: ["0", "1"] }, 3);

but we should be able to do:

new Animation(target, { opacity: [0, 1] }, 3);

In the code below #a is lightsteelblue instead of red when paused at time 0.

var foo = new Animation(document.querySelector("#a"), {"background-color": ["red", "green"]}, 2);
foo.pause();

This is because currentTime is obtained from the parent, but the DEFAULT_GROUP does not have a parent. The DEFAULT_GROUP picks up its time from a call to updateTimeMarkers() with an explicit parentTime, but this is not propagated to currentTime.

This is probably very low priority to fix, as it will be obsoleted by the upcoming switch to TimeSources.

In this example I play an animation with operation:"replace" and then one with operation:"add":

var replace = new Animation(target, {left: ["0px","50px"]}, 0.2);
var player = document.timeline.play(replace);

setTimeout(function() {
// works if the next line is commented
player.source = null;
var add = new Animation(target, {left: ["0px", "100px"], operation: "add"}, 0.2);
document.timeline.play(add);

If I set the first animation's player.source to null, the second animation with operation:"add" doesn't work. If I don't, it works.

Currently we don't use performance timing, even when it's available, unless the RAF implementation is unprefixed. This is due to concerns that prefixed RAF implementations use the wrong time origin.

See web-animations/web-animations-js@8495f01

Currently, the zero point of document time is when the polyfill loads. We agreed at the recent face-to-face that the zero point should be at document load time (at least for the default group / default timeline). See https://etherpad.mozilla.org/ep/pad/view/ro.e9QRyeowiu6/latest

Presumably we'll use window.performance.loadEventStart. See http://www.w3.org/TR/navigation-timing/#dom-performancetiming-loadstart

These are generated by the new test framework. They clutter the log and get in the way of debugging.

Assigning to Doug as I'm not sure what his plan is here.

A few examples tested on version 19.0.2:

test-calc.html
test-color-names.html
test-color.html
test-composite-transforms.html
test-iteration-start.html

Many of these tests appear to exclusively use -webkit-transform.

The spec supports a concept of TimingEvents (https://dvcs.w3.org/hg/FXTF/raw-file/default/web-anim/index.html#timing-events).

Will TimingEvents be supported in the polyfill?

To synchronize actions with animations, it's particularly important to support an end event. Perhaps this could be implemented ahead of full support for TimingEvents.

var anim = new ParGroup();
anim.add(...);
anim.currentTime = ...;

vs

var anim = new ParGroup();
anim.currentTime = ...;
anim.add(...);

This avoids unintuitive behaviour when iterations are applied.

New test framework sometimes underestimates the total duration of the animations being tested.

For example, test-iterations-fill.html should have a total duration of 1 + 3 * 8 / 2 = 13. The new framework shows a maximum time of 12, though the animation appears to continue beyond this point.

Given:

anim = new Animation(/* ... */);
anim.reverse();

Expected result: anim plays in reverse
Actual result: anim acts as if it's initially paused. Calling play does play the animation in reverse as expected.

See: https://github.com/sorvell/web-animations-js/blob/master/smoketests/test-reverse.html

It would be extremely helpful to have animations using the 'transform' property work cross-browser.

Rather than requiring users to duplicate animation values for -moz-transform, -webkit-transform, -ms-transform, transform, etc., the polyfill could feature detect the client's actual transform property and normalize an animation using the standard 'transform' property to the supported property name.

Currently we don't update timedItems when we call play and pass them as a parameter. This means that:

• currentTime is incorrect until a raf cycle
• media doesn't update pause state, etc. until a raf cycle

We should include an update step on timedItems when play is called to ensure the timeline is immediately placed into a consistent state.

sandyphan@553df99

No reason we couldn't have number of iframes equal to the number of cores and run multiple tests in parallel.

new Animation(topObjects[i], {left: ["100px", "600px"]}, 2);
new Animation(topObjects[i], {left: ["100px", "600px"]}, 2);
var parentAnimation = new ParGroup(document.animationTimeline.children);

The above code causes an error "Uncaught RangeError: Maximum call stack size exceeded"

How do I specify an accumulate operation?

new Animation(target, {left: ["0px","50px"], accumulateOperation:"accumulate"})

doesn't seem to work.

The spec states that the local time of a timed item is the sum of the timed item's inherited time and its start time. It should be the inherited time less the start time. Note that the example is correct.

See agenda item 2 of https://etherpad.mozilla.org/ep/pad/view/ro.g4AmirOCYzH/latest and https://etherpad.mozilla.org/ep/pad/view/ro.gsZ7DnSJB9X/latest

Once we've decided on the semantics of this method, it needs to be implemented in the polyfill. See agenda item 4 of https://etherpad.mozilla.org/ep/pad/view/ro.gsZ7DnSJB9X/latest

See https://dvcs.w3.org/hg/FXTF/raw-file/separate-api/web-anim/index.html#the-timeline-interface

Bug report from Sarah ...

... the problem seems to be when you have children of a parent SeqGroup of differing types. For example, ParGroups and SeqGroups, or ParGroups and Animations, etc. In the code attached, I have a SeqGroup parent with three different versions of the children. The currently uncommented one (SeqGroup followed by a ParGroup) produces the closest bug to the one in the original Car.html file.

The really interesting bit is the first commented out sgroup (a ParGroup followed by a SeqGroup) produces a slightly different bug. In this case, the animation doesn't play correctly at all, including the first time. The final sgroup is similar to this one.

SVG element transforms do not appear in computed style (at least in webKit). We need a way to test these that will work both in the polyfill and in native code. Probably the easiest way is to add bounding box testing.