1170425 - Store the owning element on CSS animations and CSS transitions

Status: RESOLVED DUPLICATE of bug 1171817

(Core :: DOM: Animation, defect)

Description

[Brian Birtles (:birtles, Feb 26~ parental leave)]

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.

Comment 1

[Brian Birtles (:birtles, Feb 26~ parental leave)]

Attachment: Add CSSAnimation::GetOwningElement

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.

Comment 2

[Brian Birtles (:birtles, Feb 26~ parental leave)]

Attachment: Add CSSTransition::GetOwningElement

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

Comment 3

[Brian Birtles (:birtles, Feb 26~ parental leave)]

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