There's a distinction between an animation's target element and the owner element of a CSS animation/transition. It's possible to use the Web Animations API to change the target element of an animation/transition or remove it altogether. However, the element that created the animation/transition (and which is keeping it alive) doesn't change. That's significant in a few cases including the following: a) When we sort CSS animations, we sort using the position of the animations listed in the animation-name property of the *owning* element. Similarly for transitions (although based on the style change event / transition property). b) When we dispatch CSS animation/transition events they should be dispatched to the *owning* element, even if the animation is no affecting a different target element. I started to implement this as part of bug 1150810 but then I realized I could fix that bug without this (since we don't allow modifying an animation's effect yet). I've split this off into a separate bug partly as a parking space for those patches but also because we might not want to land this until we make effects mutable / nullable.

In order to sort CSS animation objects correctly, we need to know which element's animation-name property they appear in, if any. Normally that's simply the target element of the animation's keyframe effect but it can differ in the following cases: 1) When script modifies a CSSAnimation's effect to target a different element (or simply removed the effect altogether). In this case we use the *owning* element to determine the priority of the animation, not the target element. This is not yet supported but we expect it to be supported before too long. 2) When script creates a CSSAnimation object using the CSSAnimation constructor. In this case, the owning element should be empty (null) and we should determine the priority of the animation in the same way as any other Animation object. Again, this is not yet supported (or even specced) but will be eventually. 3) When script holds a reference to a CSSAnimation object but then updates the animation-name property such that the animation object is cancelled. In this case the owning element should be cleared (null) so we know to not to try and sort this with regard to any animation-name property. This is possible using code such as the following: elem.style.animation = 'a 5s'; var a = elem.getAnimations()[0]; elem.style.animation = 'b 5s'; a.play(); // Bring a back to life document.timeline.getAnimations(); // ^ At this point we need to know how to sort 'a' and 'b' which depends // on recognizing that a is no longer part of an animation-name list. Note that we will also need this information in future to dispatch events to the correct element in circumstances such as (1) once we separate updating timing information (including events) from applying animation values.

This patch applies the same treatment to CSS transitions that we applied to CSS animations in the previous patch in this series.

I've included this work in bug 1171817 so if that passes review ok, I'll just close it here.