Re: [web-animations] Fixing getAnimations()

[Brian Birtles]

Hi Kevin,

Thanks for your mail.

On 2015/11/30 6:31, Kevin Doughty wrote:

Why is there a distinction between CSS transitionProperty and CSS
animationName and script based animation id? Why are these three not one
and the same?


All Animations have an id which is essentially Animation's name. You can 
put an id on transitions or CSS animations or script-generated 
animations and search on them.


In addition to that, transitions have a transitionProperty field so you 
can easily see what property triggered the animation, even the animation 
has been modified since (so you know how to cancel it from style).


Likewise, CSS animations also have an animationName field so you can 
tell what @keyframes rule(s) generated it. That's useful for DevTools 
and the like so they can let the author tweak the original style that 
generated the animation even if something else has changed the 
animation's id since then.


Incidentally, having those separate properties to filter on also makes 
it easy to get just transitions of the 'opacity' property without 
accidentally picking up CSS animations named 'opacity' or animations 
that script has tagged with the id 'opacity'. So while it's probably not 
strictly necessary to be able to filter on these properties, I think 
allowing that makes using getAnimations() more robust since you're more 
likely to get what you asked for.



I do want a way to access all animations vs. a single
keyed accessor.


I believe 'id' gives you that, although we don't have a way to set ids 
for CSS animations/transitions from markup yet, only from script.



Something like getAnimations() and getAnimationNamed().
But how about you let getAnimations operate on a NodeList instead of
creating parallel API (like the subtree boolean) to do the same tasks?
document.querySelectorAll(...).getAnimations()


That's an interesting idea. I'm not sure how much enthusiasm there is 
for extending NodeList. I think the current tendency is to use native 
Array objects rather than smart-list objects where we can.


I think extending Element and PseudoElement is a good first step, 
however. For one thing NodeList doesn't handle pseudo-elements, and if 
the extend Element, it's fairly easy to apply it to the elements in 
NodeList. We can extend NodeList later if it proves useful.



If the user wants to recall animations they should give them a name. Too
many conveniences make an API hard to grasp, when all one needs to do is
loop through and filter.


I think the use cases for this API are fairly varied, e.g.

  "Does this element have anything animating its scale?"
  "Is this element at rest?"
  "Restart all the animations on this slide"

I don't think you want to require authors to go through and name all the 
animations just to do these things. Perhaps one of the differences here 
with CA is that we're operating in an environment where animations may 
be defined by many different sources such as third-party 'theme' 
stylesheets, UA styles etc.


Best regards,

Brian


On Thu, Nov 26, 2015 at 1:38 AM, Rachel Nabors > wrote:

I concur these are issues. I like the way your thinking is going.


photo   
*Rachel Nabors*
Web Animation Engineer
w:rachelnabors.com 







Curator of Web Animation Weekly 


On Wed, Nov 25, 2015 at 6:40 PM Brian Birtles > wrote:

Hi,

Web Animations defines Animatable.getAnimations() (where
Animatable is
implemented by Element and a forthcoming PseudoElement
interface) and I
think we've agreed to add Document.getAnimations() as well.[1]

I've found two problems with the first method which I'm going to
call
Element.getAnimations() for now since PseudoElement doesn't
exist yet.


PROBLEM 1. Element.getAnimations() doesn't work on a subtree

Recently I was working on a presentation where I wanted to use
script to
restart all the animations in a particular slide, represented by a
 element.

What I really wanted to do was something like:

section.getAnimations().forEach(anim => anim.currentTime = 0);

However, Element.getAnimations() doesn't return animations from its
descendants (unlike querySelectorAll, getElementById, etc.).

To further complicate things, Document.getAnimations() *does* return
animations from its desendants (or will, once it is specced).


PROBLEM 2. getAnimations() relies too much on the order in which
animations are returned

Whenever you 

Re: [web-animations] Fixing getAnimations()

[Kevin Doughty]

Why is there a distinction between CSS transitionProperty and CSS
animationName and script based animation id? Why are these three not one
and the same? I do want a way to access all animations vs. a single keyed
accessor. Something like getAnimations() and getAnimationNamed(). But how
about you let getAnimations operate on a NodeList instead of creating
parallel API (like the subtree boolean) to do the same tasks?

document.querySelectorAll(...).getAnimations()

If the user wants to recall animations they should give them a name. Too
many conveniences make an API hard to grasp, when all one needs to do is
loop through and filter.

On Thu, Nov 26, 2015 at 1:38 AM, Rachel Nabors 
wrote:

> I concur these are issues. I like the way your thinking is going.
>
>
> [image: photo]
> *Rachel Nabors*
> Web Animation Engineer
> w:rachelnabors.com
>   
> 
> 
> --
>
> Curator of Web Animation Weekly 
>
>
>
> On Wed, Nov 25, 2015 at 6:40 PM Brian Birtles 
> wrote:
>
>> Hi,
>>
>> Web Animations defines Animatable.getAnimations() (where Animatable is
>> implemented by Element and a forthcoming PseudoElement interface) and I
>> think we've agreed to add Document.getAnimations() as well.[1]
>>
>> I've found two problems with the first method which I'm going to call
>> Element.getAnimations() for now since PseudoElement doesn't exist yet.
>>
>>
>> PROBLEM 1. Element.getAnimations() doesn't work on a subtree
>>
>> Recently I was working on a presentation where I wanted to use script to
>> restart all the animations in a particular slide, represented by a
>>  element.
>>
>> What I really wanted to do was something like:
>>
>>section.getAnimations().forEach(anim => anim.currentTime = 0);
>>
>> However, Element.getAnimations() doesn't return animations from its
>> descendants (unlike querySelectorAll, getElementById, etc.).
>>
>> To further complicate things, Document.getAnimations() *does* return
>> animations from its desendants (or will, once it is specced).
>>
>>
>> PROBLEM 2. getAnimations() relies too much on the order in which
>> animations are returned
>>
>> Whenever you see code using getAnimations(), it almost always looks like
>> this:
>>
>>var anim = elem.getAnimations()[0];
>>
>> That's really brittle. If some style is added that causes a transition
>> to fire on elem, you may end up getting the wrong result.
>>
>> Of course, you can go through all the animations returned from
>> getAnimations() and test their animationName/transitionProperty
>> attributes and make sure you get the right object, but most people won't
>> bother.
>>
>>
>> PROPOSAL: Add some options to getAnimations()
>>
>> At a minimum, I think we need:
>>
>> * transitionProperty - used to filter by 'transitionProperty' which is
>>only set on CSS transitions
>>
>> * animationName - used to filter by 'animationName' which is only set on
>>CSS animations
>>
>> * id - used to filter by 'id' which may be set on script-generated
>>animations
>>
>> * subtree - true means to fetch animations from descendents too (based
>>on the Mutation Observer API)
>>
>> It's not obvious to me what the default value of subtree should be. I'd
>> say 'false' except that would prevent using the same options object on
>> Document.getAnimations(). Perhaps true? Given that most people will use
>> this on leaf nodes anyway, maybe that would be ok?
>>
>> It's also not clear if we should only inspect the transitionProperty on
>> CSSTransition objects, or if script-generated objects that define their
>> own transitionProperty should be considered too. I guess they should.
>> Likewise for animationName and CSS Animations.
>>
>> Some usage patterns are bogus, e.g. passing subtree:false to
>> Document.getAnimations() or specifying both transitionProperty and
>> animationName (except in rare cases where script added these
>> properties), but maybe that's ok.
>>
>> Example usage:
>>
>>// Get the animation I just added
>>elem.style.animation = 'move 3s';
>>var anim = elem.getAnimations({ animationName: 'move' })[0];
>>
>>// Get all transform transitions in this section
>>section.classList.add('move-in');
>>var transitions =
>>  section.getAnimations({ transitionProperty: 'transform' });
>>
>> As you can see in the first example, we still have the '[0]' thing
>> there. It's more safe now since we're only dealing with CSS Animations
>> named 'move', but you could still get the wrong result and it's also a
>> bit of an eyesore and pain to type.
>>
>> I wonder if it's worth following the querySelector/querySelectorAll
>> pattern and having a pair of functions: getAnimation/getAnimations?
>>
>> In the singular, if there were multiple matches on the same element
>> you'd return the one 

Re: [web-animations] Fixing getAnimations()

[Kevin Doughty]

I want to add that the problem with Apple’s Core Animation view animation
for AppKit is that there is no way to specify what name is used for
implicit animation (CSS transition behavior). Animations get added with a
name that is the same as the property being transitioned (in most cases).
This prevents multiple animations running concurrently on the same
property, and is what I want resolved. For additive transitions in Core
Animation, still, the only solution is to use method-swizzling (monkey
patching). I've suggested a naming property for Web-Animations, something
like “transition-naming” with values “exact”, “none”, and “increment”, but
I concede it is awkward. An alternate to allow multiple animations with the
same name, returned in an array, would be even worse.

On Sun, Nov 29, 2015 at 4:31 PM, Kevin Doughty  wrote:

> Why is there a distinction between CSS transitionProperty and CSS
> animationName and script based animation id? Why are these three not one
> and the same? I do want a way to access all animations vs. a single keyed
> accessor. Something like getAnimations() and getAnimationNamed(). But how
> about you let getAnimations operate on a NodeList instead of creating
> parallel API (like the subtree boolean) to do the same tasks?
>
> document.querySelectorAll(...).getAnimations()
>
> If the user wants to recall animations they should give them a name. Too
> many conveniences make an API hard to grasp, when all one needs to do is
> loop through and filter.
>
> On Thu, Nov 26, 2015 at 1:38 AM, Rachel Nabors 
> wrote:
>
>> I concur these are issues. I like the way your thinking is going.
>>
>>
>> [image: photo]
>> *Rachel Nabors*
>> Web Animation Engineer
>> w:rachelnabors.com
>>   
>> 
>> 
>> --
>>
>> Curator of Web Animation Weekly 
>>
>>
>>
>> On Wed, Nov 25, 2015 at 6:40 PM Brian Birtles 
>> wrote:
>>
>>> Hi,
>>>
>>> Web Animations defines Animatable.getAnimations() (where Animatable is
>>> implemented by Element and a forthcoming PseudoElement interface) and I
>>> think we've agreed to add Document.getAnimations() as well.[1]
>>>
>>> I've found two problems with the first method which I'm going to call
>>> Element.getAnimations() for now since PseudoElement doesn't exist yet.
>>>
>>>
>>> PROBLEM 1. Element.getAnimations() doesn't work on a subtree
>>>
>>> Recently I was working on a presentation where I wanted to use script to
>>> restart all the animations in a particular slide, represented by a
>>>  element.
>>>
>>> What I really wanted to do was something like:
>>>
>>>section.getAnimations().forEach(anim => anim.currentTime = 0);
>>>
>>> However, Element.getAnimations() doesn't return animations from its
>>> descendants (unlike querySelectorAll, getElementById, etc.).
>>>
>>> To further complicate things, Document.getAnimations() *does* return
>>> animations from its desendants (or will, once it is specced).
>>>
>>>
>>> PROBLEM 2. getAnimations() relies too much on the order in which
>>> animations are returned
>>>
>>> Whenever you see code using getAnimations(), it almost always looks like
>>> this:
>>>
>>>var anim = elem.getAnimations()[0];
>>>
>>> That's really brittle. If some style is added that causes a transition
>>> to fire on elem, you may end up getting the wrong result.
>>>
>>> Of course, you can go through all the animations returned from
>>> getAnimations() and test their animationName/transitionProperty
>>> attributes and make sure you get the right object, but most people won't
>>> bother.
>>>
>>>
>>> PROPOSAL: Add some options to getAnimations()
>>>
>>> At a minimum, I think we need:
>>>
>>> * transitionProperty - used to filter by 'transitionProperty' which is
>>>only set on CSS transitions
>>>
>>> * animationName - used to filter by 'animationName' which is only set on
>>>CSS animations
>>>
>>> * id - used to filter by 'id' which may be set on script-generated
>>>animations
>>>
>>> * subtree - true means to fetch animations from descendents too (based
>>>on the Mutation Observer API)
>>>
>>> It's not obvious to me what the default value of subtree should be. I'd
>>> say 'false' except that would prevent using the same options object on
>>> Document.getAnimations(). Perhaps true? Given that most people will use
>>> this on leaf nodes anyway, maybe that would be ok?
>>>
>>> It's also not clear if we should only inspect the transitionProperty on
>>> CSSTransition objects, or if script-generated objects that define their
>>> own transitionProperty should be considered too. I guess they should.
>>> Likewise for animationName and CSS Animations.
>>>
>>> Some usage patterns are bogus, e.g. passing subtree:false to
>>> Document.getAnimations() or specifying both 

[web-animations] Fixing getAnimations()

[Brian Birtles]

Hi,

Web Animations defines Animatable.getAnimations() (where Animatable is 
implemented by Element and a forthcoming PseudoElement interface) and I 
think we've agreed to add Document.getAnimations() as well.[1]


I've found two problems with the first method which I'm going to call 
Element.getAnimations() for now since PseudoElement doesn't exist yet.



PROBLEM 1. Element.getAnimations() doesn't work on a subtree

Recently I was working on a presentation where I wanted to use script to 
restart all the animations in a particular slide, represented by a 
 element.


What I really wanted to do was something like:

  section.getAnimations().forEach(anim => anim.currentTime = 0);

However, Element.getAnimations() doesn't return animations from its 
descendants (unlike querySelectorAll, getElementById, etc.).


To further complicate things, Document.getAnimations() *does* return 
animations from its desendants (or will, once it is specced).



PROBLEM 2. getAnimations() relies too much on the order in which 
animations are returned


Whenever you see code using getAnimations(), it almost always looks like 
this:


  var anim = elem.getAnimations()[0];

That's really brittle. If some style is added that causes a transition 
to fire on elem, you may end up getting the wrong result.


Of course, you can go through all the animations returned from 
getAnimations() and test their animationName/transitionProperty 
attributes and make sure you get the right object, but most people won't 
bother.



PROPOSAL: Add some options to getAnimations()

At a minimum, I think we need:

* transitionProperty - used to filter by 'transitionProperty' which is
  only set on CSS transitions

* animationName - used to filter by 'animationName' which is only set on
  CSS animations

* id - used to filter by 'id' which may be set on script-generated
  animations

* subtree - true means to fetch animations from descendents too (based
  on the Mutation Observer API)

It's not obvious to me what the default value of subtree should be. I'd 
say 'false' except that would prevent using the same options object on 
Document.getAnimations(). Perhaps true? Given that most people will use 
this on leaf nodes anyway, maybe that would be ok?


It's also not clear if we should only inspect the transitionProperty on 
CSSTransition objects, or if script-generated objects that define their 
own transitionProperty should be considered too. I guess they should. 
Likewise for animationName and CSS Animations.


Some usage patterns are bogus, e.g. passing subtree:false to 
Document.getAnimations() or specifying both transitionProperty and 
animationName (except in rare cases where script added these 
properties), but maybe that's ok.


Example usage:

  // Get the animation I just added
  elem.style.animation = 'move 3s';
  var anim = elem.getAnimations({ animationName: 'move' })[0];

  // Get all transform transitions in this section
  section.classList.add('move-in');
  var transitions =
section.getAnimations({ transitionProperty: 'transform' });

As you can see in the first example, we still have the '[0]' thing 
there. It's more safe now since we're only dealing with CSS Animations 
named 'move', but you could still get the wrong result and it's also a 
bit of an eyesore and pain to type.


I wonder if it's worth following the querySelector/querySelectorAll 
pattern and having a pair of functions: getAnimation/getAnimations?


In the singular, if there were multiple matches on the same element 
you'd return the one with the highest composite order[2] since that's 
most likely to be the one that you want. If you had multiple matches 
within a subtree, I'm not sure: tree order or composite order.


Possible future extensions:

* Parameters to get only CSS transition or only CSS animations?
* Parameters to get all animations that affect certain properties? e.g.
  all animations that affect either the 'opacity' property or
  'visibility' property.

These can be easily implemented using Array.filter() so there's no 
urgency for these.


What do you think?

Brian


[1] https://lists.w3.org/Archives/Public/public-fx/2015JulSep/0073.html
[2] http://w3c.github.io/web-animations/#the-effect-stack

Re: [web-animations] Fixing getAnimations()

[Rachel Nabors]

I concur these are issues. I like the way your thinking is going.


[image: photo]
*Rachel Nabors*
Web Animation Engineer
w:rachelnabors.com
  


--

Curator of Web Animation Weekly 



On Wed, Nov 25, 2015 at 6:40 PM Brian Birtles  wrote:

> Hi,
>
> Web Animations defines Animatable.getAnimations() (where Animatable is
> implemented by Element and a forthcoming PseudoElement interface) and I
> think we've agreed to add Document.getAnimations() as well.[1]
>
> I've found two problems with the first method which I'm going to call
> Element.getAnimations() for now since PseudoElement doesn't exist yet.
>
>
> PROBLEM 1. Element.getAnimations() doesn't work on a subtree
>
> Recently I was working on a presentation where I wanted to use script to
> restart all the animations in a particular slide, represented by a
>  element.
>
> What I really wanted to do was something like:
>
>section.getAnimations().forEach(anim => anim.currentTime = 0);
>
> However, Element.getAnimations() doesn't return animations from its
> descendants (unlike querySelectorAll, getElementById, etc.).
>
> To further complicate things, Document.getAnimations() *does* return
> animations from its desendants (or will, once it is specced).
>
>
> PROBLEM 2. getAnimations() relies too much on the order in which
> animations are returned
>
> Whenever you see code using getAnimations(), it almost always looks like
> this:
>
>var anim = elem.getAnimations()[0];
>
> That's really brittle. If some style is added that causes a transition
> to fire on elem, you may end up getting the wrong result.
>
> Of course, you can go through all the animations returned from
> getAnimations() and test their animationName/transitionProperty
> attributes and make sure you get the right object, but most people won't
> bother.
>
>
> PROPOSAL: Add some options to getAnimations()
>
> At a minimum, I think we need:
>
> * transitionProperty - used to filter by 'transitionProperty' which is
>only set on CSS transitions
>
> * animationName - used to filter by 'animationName' which is only set on
>CSS animations
>
> * id - used to filter by 'id' which may be set on script-generated
>animations
>
> * subtree - true means to fetch animations from descendents too (based
>on the Mutation Observer API)
>
> It's not obvious to me what the default value of subtree should be. I'd
> say 'false' except that would prevent using the same options object on
> Document.getAnimations(). Perhaps true? Given that most people will use
> this on leaf nodes anyway, maybe that would be ok?
>
> It's also not clear if we should only inspect the transitionProperty on
> CSSTransition objects, or if script-generated objects that define their
> own transitionProperty should be considered too. I guess they should.
> Likewise for animationName and CSS Animations.
>
> Some usage patterns are bogus, e.g. passing subtree:false to
> Document.getAnimations() or specifying both transitionProperty and
> animationName (except in rare cases where script added these
> properties), but maybe that's ok.
>
> Example usage:
>
>// Get the animation I just added
>elem.style.animation = 'move 3s';
>var anim = elem.getAnimations({ animationName: 'move' })[0];
>
>// Get all transform transitions in this section
>section.classList.add('move-in');
>var transitions =
>  section.getAnimations({ transitionProperty: 'transform' });
>
> As you can see in the first example, we still have the '[0]' thing
> there. It's more safe now since we're only dealing with CSS Animations
> named 'move', but you could still get the wrong result and it's also a
> bit of an eyesore and pain to type.
>
> I wonder if it's worth following the querySelector/querySelectorAll
> pattern and having a pair of functions: getAnimation/getAnimations?
>
> In the singular, if there were multiple matches on the same element
> you'd return the one with the highest composite order[2] since that's
> most likely to be the one that you want. If you had multiple matches
> within a subtree, I'm not sure: tree order or composite order.
>
> Possible future extensions:
>
> * Parameters to get only CSS transition or only CSS animations?
> * Parameters to get all animations that affect certain properties? e.g.
>all animations that affect either the 'opacity' property or
>'visibility' property.
>
> These can be easily implemented using Array.filter() so there's no
> urgency for these.
>
> What do you think?
>
> Brian
>
>
> [1] https://lists.w3.org/Archives/Public/public-fx/2015JulSep/0073.html
> [2] http://w3c.github.io/web-animations/#the-effect-stack
>
>