- From: Rachel Nabors <rachelnabors@gmail.com>
- Date: Thu, 26 Nov 2015 06:38:07 +0000
- To: Brian Birtles <bbirtles@mozilla.com>, "public-fx@w3.org" <public-fx@w3.org>
- Cc: "www-style@w3.org" <www-style@w3.org>
- Message-ID: <CAPFA0t1xccQu0vytpFLn6zDho_GryBEC77xfDAYQ8_O597y-Ww@mail.gmail.com>
I concur these are issues. I like the way your thinking is going. [image: photo] *Rachel Nabors* Web Animation Engineer w:rachelnabors.com <http://twitter.com/rachelnabors> <http://dribbble.com/rachelthegreat> <http://plus.google.com/u/0/+RachelNabors> <http://linkedin.com/in/rachelnabors> ------------------------------ Curator of Web Animation Weekly <http://www.webanimationweekly.com> On Wed, Nov 25, 2015 at 6:40 PM Brian Birtles <bbirtles@mozilla.com> 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 > <section> 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 > >
Received on Thursday, 26 November 2015 06:38:52 UTC