Re: [css-animations][web-animations] steps() timing function sometimes unintuitive
On 2016/03/09 7:24, Rachel Nabors wrote:
I was thinking of "steps(5, equal)" when discussing this syntax, as an
expansion of the steps() formula. I think it looks sensible, if that's
possible?
Works for me.
"start" and "end" refer to where the step takes place, while "equal"
doesn't but actually influence the length of each segment, so it's a bit
odd. Still, I think it's ok.
If we can't find a suitable keyword to stick into steps(), then another
option is to mint a completely separate function (e.g. stagger(),
quantize() etc.).
On Mon, Mar 7, 2016 at 9:00 PM Brian Birtles <bbirt...@mozilla.com
<mailto:bbirt...@mozilla.com>> wrote:
On 2012/12/21 3:46, Tab Atkins Jr. wrote:
> On Wed, Dec 19, 2012 at 6:40 PM, L. David Baron
<dba...@dbaron.org <mailto:dba...@dbaron.org>> wrote:
>> On Wednesday 2012-12-19 10:29 -0800, Tab Atkins Jr. wrote:
>>> I propose another steps value: step-mid. It splits the
animation curve
>>> into n segments, makes the first n-1 do step-end behavior, and
leaves
>>> the last to just run normally. The above example could instead be
>>> written as "steps(4, step-mid)" and have this behavior:
>>
>> I like the idea, but I find the name confusing; it sounded like
>> something that would give the first and last steps half the duration
>> of the other steps. (I also find the description quoted above
>> confusing, but the rest of the email made it clear.)
>
> I have absolutely no attachment to the name. It was the first thing
> that came to mind.
>
> I assume that Rachel's suggestion comes from her association of
> steps(n, end) with meaning "eat the end of the animation" (and
> likewise for "start"), so "none" is reasonable in that sense.
I'm not
> sure it makes sense if your understanding comes from the spec's
> explanation, though, where "end" means "transitions all at once
at the
> end of the step".
>
> Another possibility is just a new function. I'm not sure what I'd
> want to name it, though.
I spoke with Rachel and a few others about this recently and we were
wondering about the name step-equal? Unfortunately, that doesn't
translate into a function very well ('step-equal(2)'? Alternatively,
what about 'step-stagger' and 'stagger(5)', or just the function?).
I'd like to settle on this soon because Chrome is shipping
Element.animate() with support for 'step-middle' as defined by Web
Animations.[1] We went to implement this in Firefox[2] but I'm concerned
that there aren't use cases for step-middle as currently specced and
instead what we want is what Tab originally proposed in this thread.
Assuming usage is low in Chrome, I'd like to drop step-middle from Web
Animations and replace it with this revised timing function.
Best regards,
Brian
[1] http://w3c.github.io/web-animations/#typedef-step-timing-function
I didn't realize Chrome had implemented this, or else I would have
brought this up sooner.
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1248340
Re: [web-animations] Fixing getAnimations()
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 <rachelnab...@gmail.com <mailto:rachelnab...@gmail.com>> wrote: I concur these are issues. I like the way your thinking is going. photo *Rachel Nabors* Web Animation Engineer w:rachelnabors.com <http://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 <bbirt...@mozilla.com <mailto:bbirt...@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 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(
[web-animations] Do we need to store original timing values when they are invalid?
Hi,
(CC'ing www-style since the may be some precedent from CSSOM we can
apply here.)
Web Animations currently says that if I do the following:
var anim = elem.animate({ opacity: 0 },
{ duration: 1000, iterations: -1 });
I'll see the following:
anim.effect.timing.iterations; // -1
anim.effect.getComputedTiming().iterations; // 1
The idea is 'timing' is the *specified* values and *getComputedTiming()*
gives you the actual ones used in calculations.
That's helpful for things like { fill: 'auto' } since you can see what
'auto' expands to but still keep the original 'auto' value (so you can,
for example, apply that same timing object to other animations where
'auto' might expand differently).
But I wonder how important it is to preserve the original value when
it's invalid?
ASIDE: WHY WE PRESERVE INVALID KEYFRAME PROPERTY VALUES
In Web Animations, for keyframes we need to preserve invalid property
values since what is defined as invalid may vary from implementation to
implementation based on their support for different CSS properties.
* If we drop invalid property values, then an implementation that
supports the property value will produce a different set of keyframes
to an implementation that does not and that will likely break scripts
that assume a certain number or sequence of keyframes.
* If we throw an exception for invalid property values, then if the
implementation(s) the author tested with happen(s) to support the
property values, but the user views it with an implementation that
does *not* support those values, an unhandled exception will be thrown
and the whole page will break.
For those reasons, we simply preserve the invalid values and encourage
implementations to report a warning in their debug console or what not.
I don't know if the logic that applies to keyframe values applies to,
say, negative iteration counts, however.
A more interesting case is probably timing functions since they will
likely be expanded in the near future.
If the author specifies { easing: 'spring(3)' } and an implementation
doesn't support that, I think we should *not* throw an exception since
an animation with incorrect easing is better than a completely broken
page. In that case, anim.effect.getComputedTiming().easing should return
"linear" but what about anim.effect.timing.easing? Maybe preserving the
"spring(3)" is useful to show why we ended up with "linear"?
If that's the case, maybe the original example should preserve
"iterations = -1" for consistency and authors just need to be careful to
always query getComputedTiming() if they want sensible results?
What do you think?
Best regards,
Brian
[web-animations] Fixing getAnimations()
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] Rethinking document.timeline.getAnimations
On 2015/10/09 7:51, Shane Stephens wrote: Any thoughts? This seems like a really good idea. As an extra point - we don't need to solve custom animations (onsample effects that modify the document) until L2, so we don't need to think about this right now - but if we said that animations without a target element belong to the document that the timeline they reference is attached to then we might be able to deal with at least simple cases here without resorting to exposing the map. That's a good point. In future timelines won't necessarily be attached to a document directly but we can probably define this association in terms of the active document when the timeline was created or something to that effect. I'll go ahead and make the change to the spec. Best regards, Brian
Re: [web-animations] Should computedTiming return a live object?
On Sat, Oct 3, 2015 at 1:14 AM, Anne van Kesteren <ann...@annevk.nl> wrote: > On Thu, Oct 1, 2015 at 4:23 AM, Brian Birtles <bbirt...@mozilla.com> wrote: >> I'd like to change this API, probably to one of the following (listed >> roughly in order of preference). I wonder if anyone else has an opinion >> on this? > > I'm curious as to what this maps to closer to the metal. That can help > inform a reasonable low-level API. The other thing I'm wondering about > is whether it's still reasonably to introduce new synchronous layout > getters/setters. I was hoping we'd move away from that at some point. The timing part is conceptually equivalent to doing something like elem.style.animationDuration = '3s' with the difference that we update the internal value of the duration immediately, rather than waiting for a style flush. It doesn't trigger synchronous layout however. It simply queues a style update. Fetching computedTiming will flush any pending style updates if it's called on an Animation that corresponds to a CSS animation or transition (i.e. not a script-generated animation) in much the same way that calling getComputedStyle(elem).animationDuration does. It doesn't invalidate style in anyway, however.
[web-animations] Should computedTiming return a live object?
(CC-ing public-webapps and www-style since I think this API needs more
eyes on it)
Hi,
Web Animations currently has the following API[1]:
interface AnimationEffectReadOnly {
readonly attribute AnimationEffectTimingReadOnly timing;
readonly attribute ComputedTimingProperties computedTiming;
};
interface AnimationEffectTimingReadOnly {
readonly attribute double delay;
readonly attribute unrestricted doubleiterations;
readonly attribute (unrestricted double or DOMString) duration;
// etc.
};
dictionary AnimationEffectTimingProperties {
double delay = 0.0;
unrestricted doubleiterations = 1.0;
(unrestricted double or DOMString) duration = "auto";
// etc.
};
dictionary ComputedTimingProperties : AnimationEffectTimingProperties {
unrestricted double endTime;
unrestricted double activeDuration;
double? localTime;
// etc.
};
Basically, in AnimationEffectReadOnly, 'timing' points to a live object
but 'computedTiming' points to a dictionary.
Now, attributes can't use dictionary types but this was added because we
were under the impression that this would become possible in the future
similar to the way arrays can now be used using FrozenArray.
However, having thought about this more and discussed with Cameron,
this is probably not a good API in a lot of ways. For a start, having
'timing' return a live object and 'computedTiming' return a snapshot is
odd.
I'd like to change this API, probably to one of the following (listed
roughly in order of preference). I wonder if anyone else has an opinion
on this?
OPTION 1. getComputedTiming()
-
i.e. continue to return a dictionary but make it obvious it's not live.
Having 'timing' and 'getComputedTiming()' is a bit weird but the only
concrete subclass(es) of AnimationEffectReadOnly is
KeyframeEffect(ReadOnly) which has 'getFrames()' so this naming is
consistent.
OPTION 2. Replace ComputedTimingProperties with a live interface
i.e.
interface ComputedTimingReadOnly : AnimationEffectReadOnly {
readonly attribute unrestricted double endTime;
readonly attribute unrestricted double activeDuration;
readonly attribute double? localTime;
// etc.
};
This is probably easier for authors since they can just type
'effect.computedTiming.localTime' instead of
'effect.getComputedTiming().localTime' but I think we're trying to keep
away from these kind of live objects that depend on others based on our
experience with the SVG API. (Once these interfaces get constructors you
end up having to implement an 'orphaned mode' and a 'tied to this other
object mode' and it's all quite messy.)
OPTION 3. getComputedTiming(), getTiming(), setTiming()
---
If live objects are bad and inconsistency is bad, then maybe we should
rework the 'timing' member too and make it set and get dictionary
objects. The tricky part is when you want to update just a single timing
property. We'd probably need to either drop the dictionary defaults or
provide some means for doing 'effect.setTiming({ iterations: 2 })'.
Also, I think the fact that 'computed timing' is read-only while
'timing' is writeable justifies them being different (method vs
attribute).
There are other options too but the above the main ones I'm considering,
especially option 1.
If anyone has any suggestions, please let me know.
Best regards,
Brian
[1]
http://w3c.github.io/web-animations/#the-animationeffectreadonly-interface
[web-animations] Rethinking document.timeline.getAnimations
Hi, Summary: * I think we should drop AnimationTimeline.getAnimations() * I think we should add Document.getAnimations() I've been working on implementing the Web Animations model in Gecko and I've made a few observations: 1. document.timeline.getAnimations() is not really useful If you want to find all the animations running in a document it doesn't help because animations might be running on a different timeline. There's no way of getting all the timelines either so you really can't answer the question, "is this document at rest?" without iterating over all the elements in the document and calling getAnimations() on each of them. (And even then, that doesn't work for pseudo-elements). 2. Semantically, document.timeline.getAnimations() is weird Timelines are supposed to be dumb things that simply supply time values, probably one per frame. That's all. They don't manage animations. They're just like a ruler. As you move along you read off numbers. 3. Having document.timeline.getAnimations() makes extending timelines harder We've already talked many times about having different types of timelines that track, e.g. scroll position. More recently we've been talking about changing the playbackRate on timelines and how, in order to avoid changing the playbackRate for *all* animations (including transitions) content should be able to easily create new timelines and use them as a kind of simple grouping mechanism. So I think we're in the situation where we want custom timelines and soon. What's more, I think we'll want script-generated timelines soon so we can prototype new types of timelines (e.g. timelines tied to touch gestures etc.) That's a lot easier if timelines really are just sources of time values, not managers of animations. If they're managers of animations then presumably the browser will have to add magic behind the scenes so that each script-generated timeline doesn't *also* have to be responsible for maintaining its list of animations. I'd like to fix this. At the same time I'd like to try and remove a bit of magic. I'd like to make this setup a little more explainable so that we could expose more parts of the animation system in future, if need be. I'd also like to make sure this setup explains the lifetimes of animation objects. Here's how I think, conceptually, the pieces should fit together: * UAs maintain a map between all running and pending Animation objects and their timelines. This map is hidden, but could potentially be exposed later if needed. * On each frame UAs enumerate the animations in this map to tick them. * When we come to support script-generated timelines, we add an extra step where the UA first queries each timeline to get its frame time and then passes that cached time to the Animations in the subsequent step. * With regards to lifetimes, any Animation that is running or pending is kept alive by this map. * Furthermore, target elements keep alive any *effects* targeting them. * *Effects* keep alive any animation they belong to. * As a result if you create an animation and let go of it, so long as it is targetting an element, it will be kept alive until it is neither "current" nor "in effect". - until it is finished, it will be kept alive by the timeline, unless it is paused, in which case the effect will keep it alive - once it finishes, if it fills forwards, the effect will keep it alive * This gives the expected behavior even for animations without an effect, or without a timeline and it does not expose when GC occurs. * We could support script-generated Animations in the future by simply exposing the map. In API terms I propose we do the following: a. Drop AnimationTimeline.getAnimations() b. Add Document.getAnimations() Considerations: document.timeline.getAnimations() could be good, for example, for generating a kind of timeline view but I think that's a much less common case that wanting to see all the animations affecting the current document. If that became an important use case, we could simply expose the map and allow fetching the animations by timeline. Document.getAnimations() doesn't really have any relationship to the map described above. It returns all animations *targetting* elements in the document tree. As a result, there's no way of fetching an Animation you set running with no target element. For that we'd need to expose the map. Any thoughts? Brian
Re: [web animations] Global playback rate
On 2015/09/05 4:06, Rachel Nabors wrote: Been seeing a need for a global playback rate for animations. Talking with accessibility experts about older users often needing slower animations makes me think this is something individual sites if not browsers themselves would like to offer user control over. For the specific case of providing support for users who need a slower rate of animation I think the only thing needed is an extra level of abstraction added to the definition of times used by requestAnimationFrame etc. I don't think it needs an additional API for setting the rate since I don't think you want sites to be able to override it, right? Or at least, you don't want sites that are slowing down or speeding up animations for other reasons to interfere with this setting, right? Maybe an API to get the scale factor would be useful though? For other use cases, adding a global playback rate can lead to surprising side effects. For example, suppose an author wants to pause animations on the page (perhaps while a modal dialog is showing). They set document.timeline.playbackRate = 0 and the animations freeze. Then they notice that their hover transitions aren't working any more. Odd. What's more, all those things in their app that were keyed off transitionend events no longer run. In fact, suddenly the whole app is broken. One of the motivations behind timing groups (which are spec'ed in level 2[1]) is it lets you choose the subset of effects you want to synchronize and then do playback control on all of them at once. However, another approach we could take is to reuse timelines for this. For example, you can already create a new DocumentTimeline and attach animations to it. If we added playbackRate to DocumentTimeline (or perhaps AnimationTimeline) you could divide animations into different timelines and control them separately. We'd then define requestAnimationFrame as using times from the "default document timeline"[2]. The tricky part is getting animations to track the right timelines. For example, if you wanted to slow down all CSS animations and requestAnimationFrame animations without affecting transitions, you'd probably need a declarative way of getting transitions to track a different timeline. (We could say that transitions *always* track a different timeline but then I think that actually makes it more complicated. I'm happy to explore that, however, if need be.) We already know we want to support animations that run on a different type of timeline (e.g. a timeline bound to scroll position or some touch gesture) so I think the next step is probably to work on the syntax and mechanics for specifying different timelines for animations. (On a side note, I think that if we did that, it would make timing groups less important but not irrelevant. They would still provide sequencing behavior and would be useful way of expressing start-time synchronization between independent CSS animations.) Best regards, Brian [1] http://w3c.github.io/web-animations/level-2/#grouping-and-synchronization [2] http://w3c.github.io/web-animations/#default-document-timeline
Re: Need for extended cubic-beziers
Hi Amelia, Thank you for writing this up! As a high-level comment, I like it! We've discussed this feature a few times and there's even an issue in the spec describing something quite similar to this.[1] The main resistance, however, has been to the list of numbers in the syntax. Some were concerned about ease of authoring. My preference was to introduce this as a lowest common denominator for authoring tools to use and then layer canned-effects on top later. However, I didn't succeed in persuading others of that so recently we started working on an alternative approach.[2] I have a few specific comments on your proposal below. On 2015/08/12 7:22, Amelia Bellamy-Royds wrote: The series of points is converted to a series of connected cubic Bézier curve segments by grouping into sets of three: two control points followed by a vertex point. If the number of points (plus the implicit 1,1 end point) is not a multiple of three, the sequence is padded with the point 1,1 to create complete cubic Bézier setments. I like this part. I think the previous proposal didn't have this and authors had to ensure they had the correct number of points. * A multiple bounce transition could be written as follows, resulting in the curve visualized in [Figure]: cubic-bezier(0.25,0.25, 0.25,0.75, 0.3,1, 0.5,0.5, 0.6,0.5, 0.7,1, 0.85,0.8 0.9,0.8) This is probably an example of the sort of markup others were concerned about. Finally, a new function could be added to make it easier to make smooth curves: smooth-cubic-bezier([number http://dev.w3.org/csswg/css-values-3/#number-value, number http://dev.w3.org/csswg/css-values-3/#number-value]*)https://drafts.csswg.org/css-transitions/#funcdef-cubic-bezier I like this and I know that we toyed with it, but I wonder if it's still a little hard to hand-author? I had to look at the SVG pictures to work out what the effect would be. Is that the purpose? Hand-authoring? Or simply data compression? We also looked at doing something like a Catmull-Rom curve so you could specify the peaks of the bounces (rather than control points) but didn't find a neat representation for that (Catmull-Rom curves don't necessarily produce functions even if you make x monotonically increasing). Things to discuss: Given these definitions, should new pre-defined functions be introduced to represent bounce/elastic timing functions in popular JS libraries? I don't have a strong opinion. I think we need some primitive that lets you express all the things libraries do. I don't think we want to reproduce *all* the effects in those libraries but there might be a couple of effects (particularly bounce/spring effects) that are sufficiently popular that they deserve their own shorthand syntax. Is the restriction on x values appropriate? We need to ensure that the final curve is a proper function, with each x value having a single corresponding y value. Forcing vertex and control points to be in sorted x order should ensure this, but may be overly restrictive. I think this is ok. I think every proposal we've toyed with so far has had this restriction. It is nonetheless possible to draw a completely vertical arc segment with the current wording. We could address this by adding another restriction (the x values for vertex points must be strictly greater, not just greater or equal to) or we could add an interpretation rule (apply the maximum value, consistent with how the steps function works). We already have this with step timing functions right? And we have a rule for determining the result in those cases. Are the commas between every number in the cubic-bezier function necessary? Do current implementations enforce that syntax? Compare with (a) the Shapes spec which requires commas between points in a polygon, but does not allow them between x y pairs, and (b) SVG syntax, which allows commas and whitespace interchangeably, so many people with mathematical background use commas to join x y pairs and whitespace to separate them, like x1,y1 x2,y2. I'll defer to others on whether or not this is possible and adviseable but it would certainly make it easier to read if it were possible. With all that said, what do you think of the alternative proposal in [2]? The basic idea is: * Chain the existing timing functions together specifying the length / height of each piece like so: cubic-bezier(a,b,c,d) (x, y) cubic-bezier(e,f,g,h) (x2,y2) ... * You can, of course, include 'linear', 'step-start' etc. in there * You can leave out the spacing points and they'll be evenly distributed * You can leave out the timing functions too in which case they'll default to linear I don't know how you're supposed to create smooth joins between curves with this approach but I believe there was a proposal around that. Shane and others
Re: [web-animations] Animation composite order
Hi Kari, On 2015/07/17 15:31, Kari Pihkala wrote: Out of curiosity, do we even need the notion of sequence numbers? Or can animations be regarded as belonging to a list or array structure that can be enumerated and manipulated with familiar push/pop/insert/append APIs? (Apologies if this has been discussed before.) I think sequence numbers shouldn't be exposed by the API. They're just a product of how the model is described. I agree with Kris here. The use of global sequence numbers is a bit confusing. Do you think the order of the animations could be described as a script animation list? Thanks for your suggestion! I think that description is quite clear. As a minor point, I don't think it should be called the script animation list however. The reason is that script-generated animations should not be a special case but rather CSS animations / transitions are the special case. The script API generates generic Animation objects and CSS provides specialized Animation objects that apply additional rules as required by CSS markup. We need to be clear that the purpose of the list is simply ordering (i.e. implementations don't need to maintain an actual list) and describe how Animatable.getAnimations() filters this list. Also, if a script causes a CSS animation/transition to move away from idle state, then that animation is brought to the end of the script animation list. Yes, that's right except that this is only for a CSS animations/transition that is no longer tied to CSS markup. This is going to be a lot of work to spec this but I think talking about a virtual list is probably more clear than sequence numbers and easier to write. Best regards, Brian
[web-animations] Animation composite order (was: Ordering animations based on when they transition from idle)
Hi, Just following up on this thread, Shane and I discussed this a bit on IRC yesterday and we wonder if we should push ahead with adding the ability to tweak priorities soon-ish. A few points we discussed: * Priority may be confused with CSS prioritization. From here on we will refer to composite order.[1] * We want to avoid an API like z-index for setting composite order. See [2] for some extreme examples of how z-index is abused in the wild. * An API along the lines of ChildNode[3] using reference nodes is probably better. e.g. animA.compositeAfter(animB); Strawman proposal: Animation.compositeBefore(refAnim) Rewrite sequence numbers so that Animation has the same sequence number as refAnim minus 1. No idea what we should do if either animation is a CSS animation/transition bound to markup. It might throw or we might be able to do something sensible. Animation.compositeBefore(null) Makes this animation the top of the stack. Likewise Animation.compositeAfter (mostly so you can do anim.compositeAfter(null) to put it on the *bottom* of the stack.) A query method might be needed too, e.g. Animation.isBefore(). With that in mind, I'm ok with using creation-time ordering plus the quirk we described for repurposed CSS animations/transitions--namely that their sequence number is reset on their first transition from idle after being orphaned. There's still plenty of work to do to try and align all these definitions but what do you think of this approach? Best regards, Brian [1] https://github.com/w3c/web-animations/issues/100 [2] http://reports.quickleft.com/css [3] https://dom.spec.whatwg.org/#interface-childnode
Re: [web-animations] Ordering animations based on when they transition from idle
Hi Shane, I definitely agree start-time scheduling is problematic. I was just interested in why creation-time ordering is better, particularly as opposed to first-transition-from-idle (let's call it FTFI). The first two points of your mail were about the problems with TFI which I agree are weaknesses so I'll just jump to the third point which I think touched more on the advantages on creation-time ordering. On 2015/07/15 8:37, Shane Stephens wrote: (3) It is idiomatic to create animation resources separately from their scheduling. We've already seen a desire to do things like this with declarative animation and triggers, or with time sheets. It seems equally true to say that its idiomatic to create animation resources separately from their priority. Creation time ordering ties animation priority to animation creation, which means that you think about the order in which animation resources will layer at the point where you're creating the resources. That seems odd to me. It seems more natural to set up the animations with all their properties and then think about how to combine them. That's where I was going with the FTFI proposal. In contrast, TFI ordering means you need to think about animation resource ordering at each point that you start an animation. Again, having to think about priority when you create animations seems unfortunate. That's something you'll often want to delegate to a factory method of some kind, and then take care of the controlling logic elsewhere. This is slightly better than start time ordering, but not much - for example, it means that if you've started other animations in the wrong order with respect to the animation you're about to start, you are out of luck unless you want to apply potentially global updates (your only available operation is to move an animation to the top of the priority stack). For another example, how do you slot a newly played animation in between a high-priority animation and a low-priority one? You can't without restarting the high priority animation. This is where creation-time ordering seems weakest. With TFI you can shuffle animations by restarting them (saving their currentTime in between if needed). With creation-time ordering you have to create entirely new animations. The again, the same problem exists for FTFI. I guess clone()-ing is not that bad as an interim measure. I hope these arguments give a good sense for why I'm opposing the idea of moving away from creation-time ordering. Any questions / counter-arguments? I guess I'm not thrilled with any of the options. I was hoping I was forgetting something amazing about creation-time ordering! As Kris says, and as we've often acknowledged, we'll need a mechanism for explicitly setting priority in the future. Until them maybe creation-time ordering is ok. I was hoping to see how its better than FTFI but they seem much of a muchness to me. Best regards, Brian
Re: [web-animations] Ordering animations based on when they transition from idle
On 2015/07/09 11:30, Shane Stephens wrote: I wonder if this proposal is a little bit odd in that we have the following two cases: a) var anim = new CSSAnimation(...); anim.play(); b) elem.style.animation = ...; var anim = elem.getAnimations()[0]; elem.style.animation = ; anim.play(); In (a), the priority of anim is based on when the ctor is called but in (b) the priority of anim is based on when play() is called. Would it be more consistent to say that the priority of all script-generated animations is based on their first transition from idle? And for repurposed CSS animations it is their first transition from idle after being disowned by CSS? Yes, there would be more consistency between these two cases. I think that consistency here is less important than simple ordering semantics that are separable from playback, though. (As that's what started this discussion, we've already covered this in some detail, but let me know if you want me to make the case for why creation ordering is better than play() ordering again) I think that would be good. I'm afraid I can't quite remember why creation ordering is better or why this proposal is better. I'm not opposed to it but I'd like to give others a chance to check it over too. Would you mind writing quick summary of the proposal with rationale for those who haven't been following this thread? (And to that end, starting a new thread might be better.) Thanks! Brian
Re: [web-animations] Request to publish another WD of Web Animations
Hi David, On 2015/07/14 5:58, David Dailey wrote: I'm a bit confused (still). In looking through the document, it looks as though almost everything that looks like traditional animation (in terms of the 15 year old thing that people used to call a W3C Standard -- I finally understand W3C's use of the word recommendation) has been replaced by JavaScript calls. Web Animations consists of two parts: an abstract model for animation and a Javascript API for that model. The intention is that declarative technologies such as SVG's animation elements and CSS animations/transitions can be built on top of that model so that they don't have to independently define things such as timing functions or, what happens if I have a negative delay longer than the animation duration with a forwards fill mode and a non-integral repeat count?. A UA that does not support Javascript could ignore the API part of the specification altogether. On the other hand, for UAs that support script, the API provides a way of testing that the markup correctly maps to the appropriate pieces of the model. It also provides a common interface for querying and manipulating animations regardless of whether they came from CSS animations/transitions or SVG or were generated by the API itself. Questions: 1. Realistically, how long might we have until everything breaks? (By everything, I only mean the SMIL animated stuff). I think previous versions of the Web Animations document still referenced declarative animation. The current one says: The animation features in SVG 1.1 are defined in terms of SMIL Animation [SMIL-ANIMATION]. It is intended that by defining SVG’s animation features in terms of the Web Animations model, the dependency between SVG and SMIL Animation can be removed. Nothing has changed between different versions of the Web Animations document with regards to its relationship to declarative animation. The only difference I can think of is that we have added more API examples since talking about the model in the abstract is quite difficult. Other than that, Web Animations is not intended to compete with declarative technologies, but support them as Zack's message points out. On a practical note unrelated to Web Animations, I don't know of any specific intention to remove SMIL support from Firefox, but it will be hard to justify improving it if other UAs drop support for it. 2. Is the thought that all things that were previously declarative will now be done with either script or CSS? I think I'll need to see examples to understand what the putative future of animation is to look like. I recall that CSS has vowed never to do certain things that SVG does, and it shouldn't since it is wrong on 108 distinct levels. But requiring only scripted solutions would be most unfortunate as well! That does seem to be the current trend. The gap between CSS and SVG is still large, however. 3. In the past we could send messages back and forth between animation (SMIL) and JavaScript to a) trigger, for example, motion along a curve or interpolation between two curves from script and b) call script upon termination of some animation (see for example http://srufaculty.sru.edu/david.dailey/svg/SVGOpen2010/Polygons/polygons10.svg which solves, in polynomial time, a long-standing problem thought to require N! steps. A small bug in Firefox, leaving chunks of pixels on the screen has been filed) . Will that still be possible? * Motion along a curve: Yes. With the motion path module[1] it is possible to create a motion-along-a-curve animation either from CSS or using the Web Animations API (or a combination of both; for example, create the animation in CSS, pause it and trigger it later using the Web Animations API). * Interpolation between two curves: Not yet. There has been some discussion about this as you are no doubt aware.[2] The contention is around whether we should just promote SVG's 'd' attribute from the path element to a CSS property as-is, or whether we should do something better and more CSS-like and more suitable for animating instead. * Call script on termination of some animation: Yes. Web animations provides two means for this: listening to the finished promise of an Animation, or listening to finish/cancel events (not in the most recent WD since I only added it last week). CSS likewise provides animationend/transitionend events. 4. One other question, I guess for the Blinkers among you: should we stop filing bugs in Chrome and Opera until SVG incorporates Web Animations or some other way to do animation? I have a few score of examples that are currently broken in Chrome. No sense reporting bugs if SVG is going away. How about Firefox? I understand that Firefox does not intend to withdraw support for SVG1.1, but if the SVG spec no longer mentions animation, then wouldn't fixing bugs associated with it become less of a priority? It's still worth filing the bugs if you don't mind.
Re: [web-animations] Ordering animations based on when they transition from idle
On 2015/07/09 6:50, Shane Stephens wrote: On Fri, Jul 3, 2015 at 12:21 PM Brian Birtles bbirt...@mozilla.com mailto:bbirt...@mozilla.com wrote: Also, I think we need to clarify when these sequence numbers are updated. Presumably changes to tree order prior to disassociating the animations are respected. If so, I think that leaves us with: CSS animations that are owned by script (i.e. no longer associated with markup) are prioritized as follows: 1. Animations are sorted by the moment (style change event) where they were that were disassociated from style. 2. Animations that were disassociated from style at the same moment sort by document order of the (pseudo-)element they were associated with at the style change event prior to when they were disassociated. 3. Animations that were disassociated from style at the same moment and were associated with the same (pseudo-)element sort by their relative position in the computed value of the animation-name property on that element at the style change event prior to when they were disassociated. Does that sound right? (I actually hope not since I'd rather not implement it!) Yes, that sounds right. Although it's complicated, I think it's better to take on that complication as implementers rather than cause the ordering scheme for script animations to be compromised, which will hurt web devs. However, maybe we can merge the two approaches to create something that's overall simpler. What if: * style animations become script animations on their first script-mediated transition from idle (rather than at the point when they're cancelled by the style engine). This is the first point at which they can cause visual effect changes while being owned by script. * we sort only by these transitions from idle - i.e. script-generated animations. as well as style animations that have already been played once from script, don't re-sort. Thanks, that definitely seems more implementable. (And sorry, re-reading my description I notice I completely butchered the first step. I trust you worked out what I was *trying* to say.) I wonder if this proposal is a little bit odd in that we have the following two cases: a) var anim = new CSSAnimation(...); anim.play(); b) elem.style.animation = ...; var anim = elem.getAnimations()[0]; elem.style.animation = ; anim.play(); In (a), the priority of anim is based on when the ctor is called but in (b) the priority of anim is based on when play() is called. Would it be more consistent to say that the priority of all script-generated animations is based on their first transition from idle? And for repurposed CSS animations it is their first transition from idle after being disowned by CSS? i.e. for both (a) and (b), it is based on when play() is first called? Best regards, Brian
Re: [web-animations] Request to publish another WD of Web Animations
On 2015/07/01 15:59, Brian Birtles wrote: On 2015/06/18 16:24, Brian Birtles wrote: Dear all, The editors of the Web Animations specification would like to publish another Working Draft based on the current Editor's Draft.[1] A (rather long) list of changes is included at the end of this mail. We plan to publish on July 2 unless there are any objections. Unfortunately the publication has been held up and we're now aiming for July 7. The new working draft has been published: https://www.w3.org/TR/2015/WD-web-animations-1-20150707/
Re: [web-animations] Ordering animations based on when they transition from idle
On 2015/07/02 15:10, Shane Stephens wrote: I guess either you're suggesting: a) Updating animation properties triggers a global sequence number rewrite (I hope this isn't the case), or b) Script-animations and CSS animations share the same source of sequence numbers but when we come to prioritize animations we don't use them for prioritizing CSS animations (or at least we *first* sort by script vs CSS, then by document order, then finally by animation-name order which happens to match sequence number order). I'm pretty sure you're suggesting (b) but I want to be sure. Yup. What I had expressed it as was: CSS animations use sequence number as priority, and are created in tree- and list- order. CSS Animations are still prioritized absolutely above script animations (there are two lists). I think script animations should trump CSS animations. Also, I think we need to clarify when these sequence numbers are updated. Presumably changes to tree order prior to disassociating the animations are respected. If so, I think that leaves us with: CSS animations that are owned by script (i.e. no longer associated with markup) are prioritized as follows: 1. Animations are sorted by the moment (style change event) where they were that were disassociated from style. 2. Animations that were disassociated from style at the same moment sort by document order of the (pseudo-)element they were associated with at the style change event prior to when they were disassociated. 3. Animations that were disassociated from style at the same moment and were associated with the same (pseudo-)element sort by their relative position in the computed value of the animation-name property on that element at the style change event prior to when they were disassociated. Does that sound right? (I actually hope not since I'd rather not implement it!) Best regards, Brian
Re: [web-animations] Ordering animations based on when they transition from idle
On 2015/06/23 8:57, Shane Stephens wrote: An alternative proposal: CSS animations use sequence number as priority, and are created in tree- and list- order. CSS Animations are still prioritized absolutely above script animations (there are two lists). Changing an animation-name property triggers an update of all listed sequence numbers. So: elem.style.animation = 'a 2s, b 3s, c 4s'; // a: 0, b: 1, c: 2 let b = elem.getAnimations[1]; let c = elem.getAnimations[2]; elem.style.animation = 'a 2s, d 5s'; //a: 3, d: 4 c.play(); // c promoted to script animation, keeps sequence number b.play(); // b promoted to script animation, keeps sequence number elem.getAnimations(); // what is the order here? b,c,a,d Script animations have preserved text order in terms of their *definition* (which is important, see below). I'm trying to work through this (and hopefully implement it) but I think I'm not certain I understand it. Working through an example: elem.style.animation = 'a 2s'; // a: 0; var a = elem.getAnimations()[0]; var b = elem.animate(...); // b: 1; // Currently if a and b target the same property, b will win // (Actually, see below, this is probably wrong.) // Now if I do: elem.style.animation = 'a 2s, c 3s'; // From what I understand of your proposal that would give: // a: 2, c: 3 // i.e. now a beats b simply because we added an animation? Clearly I've misunderstood something. I guess either you're suggesting: a) Updating animation properties triggers a global sequence number rewrite (I hope this isn't the case), or b) Script-animations and CSS animations share the same source of sequence numbers but when we come to prioritize animations we don't use them for prioritizing CSS animations (or at least we *first* sort by script vs CSS, then by document order, then finally by animation-name order which happens to match sequence number order). I'm pretty sure you're suggesting (b) but I want to be sure. I think I was confused because at one point you suggested that the prioritization we do for CSS animations and transitions could be expressed using sequence numbers. Best regards, Brian
Re: [web-animations] Request to publish another WD of Web Animations
On 2015/06/18 16:24, Brian Birtles wrote: Dear all, The editors of the Web Animations specification would like to publish another Working Draft based on the current Editor's Draft.[1] A (rather long) list of changes is included at the end of this mail. We plan to publish on July 2 unless there are any objections. Unfortunately the publication has been held up and we're now aiming for July 7.
[web-animations] Web Animations minutes, 28 May 2015
[ Sorry for the delay here, I just discovered these notes in the Etherpad and I don't appear to have ever sent them to the list. ] Web Animations minutes, 28 May 2015 Present: Doug, Mike, Shane, Brian Archived etherpad: https://web-animations.etherpad.mozilla.org/ep/pad/view/ro.92487irtSfEow/rev.40163 Agenda: 1. Custom effects 2. Navigation transitions 3. Effect clipping 4. Stacked timing functions 1. CUSTOM EFFECTS = * This has been moved to level 2 but we'd like to get a rough outline of it so we can work on it in the polyfill * Tricky part is how to integrate with all the playback algorithms * There may be a way to integrate it into the regular sampling behavior Basic idea: * Add AnimationEffect.onsample * Any time the progress (including going to/from null) or current iteration has changed we'd call this - basically, onsample needs to be called any time the animation state changes in a way that could potentially lead to a change in the visual effect of the animation * (Some discussion about *not* calling these for offscreen elements--off-screen iframes would have a timeline that is ticked less often so might be ok?) * Should we pass the AnimationEffect to the callback? Yes, makes sense * Should we *also* pass the Animation? Probably, since you can't currently go from effect back to its animation. (Some discussion about the fact that we'll probably eventually want to be able to go from effect to animation.) * What do we do about the target? * Groups don't have targets * Do you even want GroupEffect.onsample? Or is KeyframeEffect.onsample enough? - Yes, you need GroupEffect.onsample. (e.g. a sequence group that updates a progress bar via an onsample callback as the sequence continues) * Regarding groups, the callback should be called whenever the descendant group structure changes * This also includes, e.g. tweaking the keyframes of a descendant effect (since that could produce a different visual result) * This might seem excessive but we'd still only call these once per frame. i.e. set a dirty flag and mark all ancestors dirty for that tick. * Regarding changing the target of a KeyframeEffect, that would also trigger a callback but would it also trigger 2 callbacks: once with the old target and a null progress and once with the new target and a resolved progress? (this is what is currently specced) * Previously the target was clearly a parameter of the custom effect but now that's not necessarily the case. * We *could* pass in the old target but why make the target special? Why not also pass in the old set of children etc.? Old set of children's targets? * We could just make tracking changes to the target the responsibility of the callback function. * Regarding the signature, what to pass: - progress (nullable) - effect - animation Viewport events topic: * Some discussion about where these callbacks happen within a frame * Agreed they should probably happen after rAF callbacks * Shane introduced the topic of viewport events which may create a loop that repeatedly updates style and layout. If this happens we may need to ensure that onsample callbacks participate in this loop. 2. NAVIGATION TRANSITIONS = Discussions ongoing between Google and Mozilla at the moment. Main sticking point is how to address latency. 3. EFFECT CLIPPING == * This is one of the pieces needed to polyfill groups on top of the existing features * Proposal: add a clip-start and clip-end value to Animations. These clip the fill (or animation) and are -Infinity/Infinity by default. * Use cases: polyfilling groups, representing transitions' backwards fill * It seems somewhat related to the issue about the forwards fill of animations persisting forever and clobbering subsequent style changes so we investigated a more general mechanism for cancelling fill. e.g. fill: forwards fills each property until there is a subsequent change to the property, forwards-forever fills forwards unconditionally, forwards (3s) fills for 3s We didn't really arrive at any conclusion. However, if we're going to add forwards-forever then we probably need to add that from the start otherwise we can't repurpose forwards later * Adding Animation.clipStart and clipEnd might be worthwhile but it would be great to get some validation from existing JS libraries (e.g. GSAP, Velocity), i.e. get them to use Web Animations as a backend and see what limitations they hit. If clipStart/clipEnd, for example, would solve their problems then we should definitely add them. 4. STACKED TIMING FUNCTIONS === * Stacked timing functions would allow you to emulate the effect of nested groups. * However, Brian points out that chained timing functions have the same ability to emulate arbitrary easings, and are also more accessible and
Re: [web-animations] Updating the finish promise in a separate task
On 2015/06/30 13:21, Brian Birtles wrote: Hi, I'm currently speccing finish/cancel events for animations and I think it makes sense to dispatch finish events and also update the finished promise in a separate task. I was thinking of applying similar handling to the cancel event including the part where we cancel a pending finished promise. However, a consequence of this handling is it means that in the following case: anim.finish(); anim.currentTime = 0; the finished promise won't resolve. Nor will any finish event fire. Likewise, if you say: anim.finish(); anim.cancel(); anim.currentTime = 0; The finished promise won't fulfill or reject. Nor will the finish or cancel event fire. Is that weird? I wonder if we the following behavior is more intuitive: 1. cancel() queues event dispatch / promise rejection synchronously such that calling cancel() always triggers a cancel event unless the animation is already idle. 2. finish() likewise queues event dispatch / promise resolution synchronously unlike simply setting the currentTime. (3. A timeline going inactive should cause us to update the hold time of any animation watching it. This is consistent with what happens when we set animation.timeline = null and means the only time we ever transition to the idle state is from a call to cancel().) Best regards, Brian
[web-animations] Updating the finish promise in a separate task
Hi,
I'm currently speccing finish/cancel events for animations and I think
it makes sense to dispatch finish events and also update the finished
promise in a separate task.
The would mean that something like:
var anim = elem.animate({...}, 3000);
anim.currentTime = 5000;
anim.currentTime = 1000;
would no longer resolve the finished promise immediately since we
wouldn't check the finished state until the current task had completed.
A more likely use case is something like:
var anim = elem.animate({...}, 3000);
anim.currentTime = 5000;
anim.effect.timing.duration = 1;
Note that with the current behavior this would resolve the finished
promise immediately, but if we reverse the last two lines, it would not.
By checking for updates to the finished state in a separate task,
authors don't need to be so careful about the order in which they update
animation properties.
This is mostly just a heads up but if anyone has any concerns with this
please let me know.
Best regards,
Brian
Re: [web-animations] Bubble animation events to effects
Hi Glen,
Sorry, I'm just now catching up on your feedback.
On 2015/06/25 20:58, Glen Huang wrote:
Also curious about two things:
1. Is zero duration, forwards filled, single keyframe effect valid and
fills with the keyframe?;
```
new KeyframeEffect(el, {position: static}, {fill: forwards}) // is
el's position static after the effect is played?
```
Yes, that's correct.
2. Are partial keyframes valid and properties specified in a keyframe
extends to the next one?
```
el.style.position = static;
new KeyframeEffect(el, [{
position: absolute,
prop: val1
}, {
// is position absolute in this keyframe?
prop: val2
}], {duration: 1000, fill: forwards})
```
Yes, partial keyframes are valid. The defined behavior here is:
* Since there is no keyframe at offset 1 for 'position', one will be
created with the 'neutral composition value' and 'composite: add'.[1]
* The neutral composition value is some value that, when added to the
underlying value, produces the underlying value.[2] So in this case it's
going to be some kind of null-like value (that, in this case, will
evaluate to 'static' when we add it to 'static').
As a result, this should interpolate from 'position: absolute' to
'position: static'.
Best regards,
Brian
[1]
http://w3c.github.io/web-animations/#the-effect-value-of-a-keyframe-animation-effect,
step 8
[2] http://w3c.github.io/web-animations/#neutral-value-for-composition
Thanks.
On Jun 22, 2015, at 6:21 PM, Shane Stephens sh...@google.com
mailto:sh...@google.com wrote:
On Tue, Jun 16, 2015 at 7:07 PM Glen Huang curvedm...@gmail.com
mailto:curvedm...@gmail.com wrote:
The conversation unfortunately died.
Maybe the use cases aren't compelling enough. That's totally fine.
The only question I have is that in the responding mail, you said
You can do this with closures too. Just toggle the class in the
classList.
But I don't think I can.
Your original suggestion was that I should negate styles in the
keyframes, and since the effect is only backwards filled, those
negations will go aways when the effect is no longer active.
Now, by toggling class I assume you mean I should put these
negations inside a class and enable that class when closure is
called? But now when the effect is no longer active, the class
won't be removed automatically. So when do I remove it manually?
There is no hook in the effect to notify me when the effect is no
longer active.
Basically, you set your final state in CSS then override using the
animation. For example, before the animation starts you set:
navBar.style['justify-content'] = space-between;
Then in your animation, you animate justify-content from center to
center. It holds that value while it fills forwards.
When the animation is done, use the onfinish hook to cancel it, and
the value stops applying, falling back to the final state you've set
up in CSS.
I have another use case that could be covered by this hook: when
multiple effects are nested, I want some of them to fill forwards,
but others to fill forwards until the root effect is no longer
active. With this hook, I can change the nested effect's fill to
none in the hook of the root effect.
Again though this is using events to set the visual state, which you
really shouldn't do. Instead, this sounds like some kind of advanced
groups case - given that we haven't nailed down basic groups yet I
think it's probably a way off before we consider looking at it.
You can in general get a mixture of fill effects by refactoring your
groups appropriately. This doesn't give you everything but it gets you
a long way.
Cheers,
-Shane
So the question is, since such hook doesn't exist, is there any
other way to achieve the things I described?
In general - yeah, though some of them may be difficult. Another
question, though, is 'does this hook fit with the realities of
animation' - sadly the answer here is no, because it's impossible for
us to give you an event callback in which it's safe to modify visual
state.
Cheers,
-Shane
Thank you very much.
On May 27, 2015, at 3:24 PM, Shane Stephens sh...@google.com
mailto:sh...@google.com wrote:
Hi Glen,
On Wed, May 27, 2015 at 5:09 PM Glen Huang curvedm...@gmail.com
mailto:curvedm...@gmail.com wrote:
Hi, I recently tried to manage very complex animation, and
realized I need this feature:
When animations fire ready and finish events, they first
bubble into to the associated effects, if effects have
nesting children, recursively bubble into them, after that,
bubble back to animations, much like how dom events work.
Do you think it makes sense?
I think it sounds complicated, and it doesn't match the intention
of events well. If you have some specific examples where you want
this behavior, perhaps we can work through them with you?
My use case is
[web-animations] Request to publish another WD of Web Animations
Dear all, The editors of the Web Animations specification would like to publish another Working Draft based on the current Editor's Draft.[1] A (rather long) list of changes is included at the end of this mail. We plan to publish on July 2 unless there are any objections. Best regards, Brian [1] http://w3c.github.io/web-animations/ The following changes have been made since the 5 June 2014 Working Draft: * Rewrote 1.1 Use cases to provide specific code examples and describe scenarios that do not involve using timing groups which have been deferred to a subsequent level of this specification. * Added definition of unresolved time values. * Introduced document timelines. * Renamed not started timelines as inactive timelines. * Renamed animation players to animations (what were previously referred to as animations are now keyframe effects). * Made the animation sequence number increment on each transition out of the idle state (not on creation). * Made the association between an animation and a timeline optional. * Removed the concepts of effective timeline time and effective current time. * Renamed the source content of an animation (previously, player), to its target effect. * Removed the non-normative description of seeking behavior. * Added the current finished promise and current ready promise objects to animations. * Modified the procedure to finish an animation so that pause state is not changed by finishing. * Added animation play states. * Removed player events. * Rewrote most of the algorithms for animations to accommodate asynchronous play/pause/reverse operations. * Renamed animation nodes to animation effects and what were previously known as an animations to keyframe effects. * Removed the start time specific to an animation effect since it is always zero in the absence of groups effects. * Removed the term inherited time since, in the absence of animation effect-specific start times, local time is equivalent to inherited time. * Renamed the time fraction to iteration progress. * Deferred group effects (previously known as animation groups) to a subsequent level of this specification. Deferring this feature also lead to the following simplifications: * Deferred the animation effect-specific playback rate since it was considered to be not particularly useful without group effects and potentially confusing (since animationss also have an animation playback rate). * Removed the repeated duration definition since it is redundant in the absence of the animation effect-specific playback rate. * Renamed intermediate animation values to effect values. * Added the concept of animation types and clarified prioritization in a way that can be easily extended by CSS Animations and CSS Transitions. * Removed motion path animation effects since this functionality can be achieved using the Motion Path Module. * Deferred custom effects to a subsequent level of this specification. * Defined that unresolved time values are represented by null. * Added the DocumentTimeline interface. * Renamed the getAnimationPlayers method of the AnimationTimeline interface to getAnimations(). * Made the getAnimations() method on the AnimationTimeline and Animatable interfaces return all animations that are either current or in effect. * Moved the play() method of AnimationTimeline to a subsequent level of this specification. * Renamed the AnimationPlayer interface to Animation. * Updated the Animation interface: * Added the Animation() constructor. * Made startTime nullable. * Added the playState member and corresponding AnimationPlayState enum. * Added the ready and finished Promise attributes. * Removed the paused and finished boolean attributes. * Removed the onfinish attribute. * Renamed the source member to Animation/effect. * Added a read-only version of interfaces for animation effects and related interfaces as follows: * Animation effects are now represented by the AnimationEffectReadOnly interface. * Animation effects are now represented by the KeyframeEffectReadOnly and Animation interfaces. * Keyframe effects are now represented by the KeyframeEffectReadOnly and KeyframeEffect interfaces. * A number of references to Animation and KeyframeEffect have been updated to refer to their read-only equivalents since the read-only interface is the super-interface in each case * Fixed the grammar for cubic-bezier-timing-function to match CSS Transitions. * Introduced the ComputedTimingProperties dictionary and AnimationEffectTimingReadOnly interface. * Moved computed timing from AnimationEffectReadOnly to a computedTiming attribute of type ComputedTimingProperties. * Removed the player attribute from the AnimationEffectReadOnly interface. * Exposed the iteration progress (was time fraction) to script as effect.computedTiming.progress. * Made the procedure defined in '5.10.2 Processing a frames
[web-animations] Web Animations minutes, 25 May 2015
Web Animations minutes, 25 May 2015
Present: Doug, Mike, Shane, Brian
Archived etherpad:
https://web-animations.etherpad.mozilla.org/ep/pad/view/ro.92487irtSfEow/rev.37544
Agenda:
1. Name property
2. Can we drop AnimationTimeline.play?
3. AnimationTimeline.getAnimations() - sequencing
4. Use cases for AnimationTimeline.getAnimations()
5. Filling forwards
6. CSS animations and transitions specs
7. Filter for CSS vs Script getAnimations
8. Animation finish event (naming) and behavior on cancel
9. Grouping in CSS
10. Interaction of animation-play-state and the API
11. Generalized event dispatch
1. NAME PROPERTY
=
(Brian)
Ideally, I'd like to have:
* CSSAnimation.animationName (to indicate what animation-name generated
the object even if the effect gets replaced)
* CSSKeyframeEffect.rule (let's you do animation.effect.rule.name)
* CSSTransition.transitionProperty
I was wondering about dropping the name property altogether.
After discussion, we think there's still use in having an
author-settable property purely for informational purposes, i.e.
* Animation.id
The 'id' name is following the precedent from ServiceWorkers and DOM.
Although 'id' may suggest the name should be unique, we don't ancitipate
having any requirement for this.
Mike: so can you write to animationName?
Shane: no I think animationName / rule / transitionProperty are all read
only as they come from the style sheet.
Brian: it might be a good idea to add a query-by-id method to L2 of the
specification, e.g. as a parameter to getAnimations.
2. CAN WE DROP AnimationTimeline.play?
==
Instead of:
anim = document.timeline.play(new KeyframeEffect(elem, {..}, 1000);
You can already do:
anim = new Animation(new KeyframeEffect(elem, {..}, 1000),
document.timeline);
anim.play();
(As well, of course as elem.animate({..}, 1000))
Shane: my only concern is how this looks with groups
from:
anim = document.timeline.play(new SequenceEffect([...]));
to:
anim = new Animation(new SequenceEffect([..]), document.timeline);
anim.play();
Actually that's not any different really. But we have element.animate
for individual animations and nothing for groups if we remove
AnimationTimeline.play().
Q: How do you associate an animation with a timeline post-construction?
A: animation.timeline = ...;
Could we add document.start? Or document.play?
Move it to level 2 where we can also think about how to make
constructing groups easier
3. AnimationTimeline.getAnimations() - SEQUENCING
=
See summary of issues here:
https://github.com/w3c/web-animations/issues/62
Current proposal is:
https://github.com/w3c/web-animations/issues/62#issuecomment-104486590
Seems like we could probably drop 1.i
4. USE CASES FOR AnimationTimeline.getAnimations()
==
(Brian)
* At first I wondered: is it even needed?
* More common use-case document.getAnimations() -- e.g. are the elements
in this doc at rest?
* Or: elem.getAnimations({ deep: true }); -- e.g. is this sub-tree at rest?
* Perhaps similarly: elem.getAnimations({ includePseudos: true }); (but
I'm less sure of this. Seems like we should just expose a means of
getting CSSPseudoElement objects and call getAnimations() on them.)
However:
* AnimationTimeline.getAnimations() is still useful as a way of getting
animations that aren't attached to any element
Doug: I suspect people will use Timelines as a primitive grouping
mechanism, especially if we provide getAnimations.
For the time being, we realise we need
AnimationTimeline.getAnimations() as a way of representing animations
that don't target an element -- they need somewhere to live and
something that (conceptually at least) keeps them alive since they
will still dispatch events, fulfill promises etc.
5. FILLING FORWARDS
===
Two issues:
1. For script-generated animations, continually creating
forwards-filling animations will leak memory over time. (The same
issue doesn't apply to CSS animations since you typically replace the
animations, or at least you obviously see you're leaking memory by
creating a massive animation-name list.)
2. When you have a forwards-filling animation it clobbers other changes
to style which can be very confusing. In the case where some
script/content you don't control is creating the forwards-filling
animation you either have to try writing to style and see if it
works, or use getAnimations() and check the result.
(Problem 2 is also less of an issue for CSS animations as at least the
computed style carries a record of the animation that's blocking other
style updates)
For CSS animations we probably can't fix 2 due to compatibility
limitations but for script-generated animations we might be able to
address both by adding a sort of forwards fill that cancels
[web-animations] Web Animations minutes, 27 April 2015
Web Animations minutes, 27 April 2015 Present: Doug, Shane, Brian Archived etherpad: https://web-animations.etherpad.mozilla.org/ep/pad/view/ro.92487irtSfEow/rev.33376 Agenda: 1. Property-indexed keyframes 2. Finishing behavior 3. Publishing next WD 4. Negative infinity start delay 5. Add / accumulate - Append / add? 6. Renaming time fraction 7. Readonly - ReadOnly 1. PROPERTY-INDEXED KEYFRAMES = https://github.com/w3c/web-animations/pull/83 Shane: I had thought that a property-indexed keyframe was just a keyframe with the same processing algorithm to convert from a JS object into a spec object. Looking over it again, there's one minor modification that needs to be made for this to work. In 5.14.1 (http://w3c.github.io/web-animations/#processing-a-keyframe-object) step 10 we'd need to update the Member Variable part to first attempt to capture a list of things that are parsed as strings, then parse as a string if that fails. I think this probably avoids a number of the other issues. WDYT? On further discussion it seems like a PropertyIndexedKeyframe object is more desirable as it makes it clearer: * what inputs are OK when; and * what will be returned when Keyframes are extracted from KeyframeEffects. Shane to have a go at rewriting the feature Shane to remove reference to spacing keyframes 2. FINISHING BEHAVIOR = Thread starting: https://lists.w3.org/Archives/Public/public-fx/2015AprJun/0013.html * play() is probably ok for now * ready is probably ok as a unified/re-used Promise for now but we need to look out for use cases that depend on knowing if a particular call to play()/pause() completed/rejected It's hard to know if the re-using behavior is actually useful or not. It seems to help with some cases (independent modules performing different operations and then waiting on the ready promise) but in other cases may be less intuitive (e.g. calling play(), waiting on ready, then calling pause() -- authors might expect ready to reject in that case since the play() didn't complete). * How about play-pending and pause-pending states? We don't want to add too many states, especially since other operations may become async and require their own *-pending states. For now, just leave it as 'pending' and we can add 'pendingState' or some sort of substate if needed in the future. * 'finished and paused'? finish()? Make finished promise not resolve while paused Make finish() take you to finished state (i.e. not paused) * pause() while idle should resolve current time 3. PUBLISHING NEXT WD = Prerequisites: * Try to get property-indexed keyframes in (unless nothing happens by 7 May) * s/Readonly/ReadOnly/ 4. NEGATIVE INFINITY START DELAY PR: https://github.com/w3c/web-animations/pull/87 Shane to look over 5. ADD / ACCUMULATE - APPEND / ADD? Concern that if you are combining independent animations, for example, you would append for filter lists but add lengths, i.e. different operation names for the same step. 6. RENAMING TIME FRACTION = Time progress / unit progress / unit time ? unit progress fraction time :) 'iteration progress' - IDL: 'progress' 7. Readonly - ReadOnly === To match geometry spec.
[web-animations] Setting the current time in the idle state should transition to paused not running
Hi, If an animation is in the idle state and the current time is set, the currently spec'ed behavior is that the animation will transition to the running state. This is because when the current time is set, none of the conditions that would cause us to update the hold time are fulfilled.[1] As a result we end up updating the start time which will cause the animation to play. I think this is probably counter-intuitive and is certainly inconsistent. Generally speaking (ignoring pending/finished) we have the following rules applied in order: 1. current time unresolved - idle 2. start time unresolved - paused 3. otherwise - running In the idle state both current time and start time are unresolved. If the author sets the current time only I think it's natural to assume that the start time remains unresolved and the animation becomes paused. Unless anyone objects I plan to update the algorithm for setting the current time[1] such that it only updates the start time if the start time is already resolved. Best regards, Brian [1] http://w3c.github.io/web-animations/#silently-set-the-current-time
Re: [web-animations] Sampling optimization
On 2015/04/17 14:34, Glen Huang wrote: The difficulty for a JS implementation is to make sure the times reported by the timeline etc. match up with the current frame even when the polyfill is not listening for frames but something else is generating them Yes, that's the difficulty I encountered. My current solution is to cache performance.now() when the current time is requested for first time in this event loop, and then clear it in a new task (so the current time stays the same in the same event loop). Do you think it's a valid solution? That sounds reasonable. There's some discussion about exposing the frame time and frame ID to script in a future version of requestAnimationFrame which would possibly make this even easier (provided you don't have to register for requestAnimationFrame in order to get it). Having said that, I definitely think all the current references to sampling in the spec need to be rewritten. Looking forward to that. But since it won't address who pulls or pushes the time values, I guess it only clarifies when the sampling happens? That's right.
Re: [web-animations] does rescheduling create pending task?
On 2015/04/11 15:48, Glen Huang wrote: Hi Brian, Thanks for the explanation. The explanation is perfectly clear, but I'm unable to relate it to the requirement reschedule that task to run as soon as animation is ready. This doesn't seem to have anything to do with delaying the resolving of the ready promise. To me it sounds like this: the animation has a pending pause/play task, now you set a new effect to it, you should wait until the new effect's first frame is rendered and then run the task. Yes, that's right. So I'm a bit confused when you said it should be better expressed as canceling it. Maybe I misunderstood the meaning of rescheduling? If the task that resolves the promise etc. is scheduled in a queue and the effect is changed, that task should be cancelled (i.e. removed from the queue) and a new task scheduled once the new first frame has been rendered. Does that make more sense? What do you mean by effect1 being updated? I was initially under the impression that running a pending task would cause css properties specified in effect1 to be applied to its target. Now I realize that's wrong, the pending task only updates the animation object. I will ask a different question: The code example is meant to simulate the rescheduling scenario I had in mind: The animation associated with effect1 is played, but it isn't associated with a timeline, so it has a pending play task. Now the users replace effect1 with effect2, triggering the reschedule step. After the animation has been associated with a timeline, it should be considered ready, At this time, should the pending play task created when animation was associated effect 1 be run to update the animation object? I'm still not sure what you mean by update the animation object. Looking at the code we have: ```js let effect1 = new KeyframeEffect(…); let effect2 = new KeyframeEffect(…); let anim = new Animation(effect1); anim's start time and current time are both null. anim.play(); anim's hold time gets set to zero. effect1's computed timing will reflect this time. The ready task won't run, however, until anim has an active timeline.[1] anim.effect = effect2; The reschedule step happens (but the ready task was never going to run anyway without an active timeline). effect1 is no longer in effect. effect2's computed timing now reflects the time inherited from anim. (If we were to paint at this point, we'd apply the properties defined in effect2.) anim.timeline = document.timeline; We now have an active timeline but we still haven't satisfied all the conditions for being ready.[1] We still need to wait for any setup to complete such as painting the first frame of the animation. Sometime later (typically within the same frame, but not necessarily) the animation will become ready and the ready task will be run which will resolve the ready promise etc. Does that make more sense? Best regards, Brian [1] http://w3c.github.io/web-animations/#ready
Re: [web-animations] Please, provide examples for AnimationReadonly usage
On 2015/03/06 19:19, Aleksei Semenov wrote: Hello, everyone. The specification defines two interfaces: AnimationReadonly and Animation. First one is read-only, second is mutable. https://w3c.github.io/web-animations/#the-animation-interfaces The examples in the specification refer only to Animation interface. So it is not clear, what is a purpose of AnimationReadonly interface. Could you clarify this? The purpose for the KeyframeEffectReadonly interface (and other similar interfaces) is for exposing animations created by CSS / SVG etc. If an animation corresponds to a CSS animation for example, what is the expected behavior when the author changes its duration? It can't update the stylesheet that generated it because that might affect many other animations too. Trying to make it update the local style of the target element proves very difficult too because if you make independent changes to the style sheet and the API you will run into trouble because, suppose you add an animation to your 'animation' property in the stylesheet, you may get surprising results because the 'animation-duration' stored as local style has a different list length now. Trying to say, properties explicitly set through the API override those set by style creates a very confusing API because then authors need a way to inspect which properties are overridden locally and which are from style and they need a means for resetting properties to track changes to style. We tried this and it was horrible. The approach we have now is that animations created by CSS (and I expect SVG too) produce an Animation whose target effect is a KeyframeEffectReadonly object. You can perform play control on the Animation such as pausing/reversing etc. without breaking the connection with style. If, however, you want to modify the duration of the animation or any of the other properties on the KeyframeEffectReadonly object, you need to explicitly break the link with style as follows: anim.effect = anim.effect.clone(); Any changes to the cloned KeyframeEffect don't affect style and any changes to style only affect the old KeyframeEffectReadonly object which is now irrelevant. The only place where style overlaps with changes to the API is pausing and animation-play-state but since this is simply a binary state we can work out some sensible rules to allow this to behave intuitively. So, in summary, we don't expect script authors to create KeyframeEffectReadonly objects typically although there may be some use cases where it is useful. It's main purpose is to be used to expose animations created through declarative means. Best regards, Brian
Re: [web-animations] Time fraction when iteration duration is zero
On 2015/03/10 21:55, Сергей Грехов wrote: Time fraction calculation algorithm (http://w3c.github.io/web-animations/#calculating-the-time-fraction) contains several steps for the case when iteration duration is zero. It's not obvious to understand the idea of thes algorithm looking at algorithm only. May be it makes sense to add non-normative section explaining why these steps are needed and why in this case time fraction is not simply zero or 1? How does this look? https://w3c.github.io/web-animations/#calculating-the-time-fraction https://github.com/w3c/web-animations/commit/c6a45e5f8cc42a81663a6a39f74afc842c4ac553 Best regards, Brian
Re: [web-animations] the definition of animation node is weak
Hi Aleksei, On 2015/02/19 21:31, Aleksei Semenov wrote: ... As you can see, the definition of animation node does not define any additional properties, that can be used to distinguish animation nodes from other timing nodes. Furthermore, the role (or function) of animation node is also not defined. Thanks for your mail. Animation nodes will disappear when I rework the spec in a few weeks' time.[1] When I do that I'll keep in mind to avoid confusion with the generic timing nodes term. Best regards, Brian [1] https://github.com/w3c/web-animations/issues/72
Re: [web-animations] Live update to the model issue
Hi Sergey, On 2015/02/19 20:17, Сергей Грехов wrote: Hi All, Please see the second non-normative section, containing Example 19, in 5.21. Script execution and live updates to the model (https://w3c.github.io/web-animations/#script-execution-and-live-updates-to-the-model). That whole section needs to be rewritten. I've been meaning to add an issue to that section indicating that but haven't done so yet.[1] Part of the issue is that we were waiting for some definitions to be added to HTML but they have been added now so we should rewrite this. Best regards, Brian [1] https://github.com/w3c/web-animations/issues/56
Re: [web-animations] confusing picture for player limiting behavior
Hi Aleksei, Thanks for your mail. On 2015/02/18 18:48, Aleksei Semenov wrote: Hello, everyone. The section '3.5.11. Reaching the end' describes the player behavior, when it reaches its boundaries (either start or finish). The section also contains a picture to demonstrate the effect of limiting. (Please, find it attached) The description of the picture reads The effect of limiting the current time of a player with a start time of 1s,a source content of length 3s, and a positive player playback rate.After the current time of the player reaches the end of the source content, it is capped at 3s. I think the picture is not correct in the area, where timeline time is before player start time. First, the curve contains the arrow as if playback rate is negative, but description states it is positive. Sorry, I don't understand this point. Why do you suggest the playback rate is negative? Timeline time and player time both increase and decrease in proportion. If the playback rate were negative the curve would slope in the opposite direction since an increase in timeline time would cause a decrease in player time. Brian
[web-animations] Web Animations minutes, 14 Feb 2015
Web Animations minutes, 14 Feb 2015
Present: Doug, Shane, Brian
Archived etherpad:
https://web-animations.etherpad.mozilla.org/ep/pad/view/ro.92487irtSfEow/rev.32354
Agenda:
1. What is the set of animations returned from getAnimationPlayers()?
2. play(), pause etc. and returning Promises
3. Renaming time fraction to progress something?
4. Animation end behavior
5. Naming
6. List interfaces
7. What's missing from level 1 for doing a good polyfill of groups?
8. Deferring custom effects from level 1
9. Allowing animations to repeat
10. Making default timing be ease?
11. Is composite add part of level 1?
1. WHAT IS THE SET OF ANIMATIONS RETURNED FROM getAnimationPlayers()?
=
We didn't resolve this last time. Need to work this out.
CSS Animations are (might be) special, we might consider returning them
as long as their name is in animation-name.
For the dev-tools use case, may need an API in future to capture
animations as they start. The trouble is animations are often very
subtle, short-lived effects so it can be hard to catch them if the API
doesn't return them once they have finished playing.
From one point of view, returning finished non-filling CSS Animations
is consistent with style. But from another point of view, doing so is
inconsistent with the behaviour for script-generated animations.
For now, we might just continue to *not* return CSS Animations that are
not filling forwards and rely on a future API to capture animations as
they start.
2. play(), pause etc. AND RETURNING PROMISES
Background is this thread:
https://lists.w3.org/Archives/Public/public-fx/2015JanMar/0026.html
Need to revisit this:
- Have a single promise of split them up?
- Have start() which returns a promise
- Further discussion: start vs finish? resume()? unpause()?
Proposal:
Two primitive operations
pause() - pauses, returns ready promise (pause-ready promise?)
resume() - unpauses, no seeking; returns ready promise (play-ready
promise?)
If there is no start time / hold time blocks until one is set?
Two operations built on top of that:
start() - seeks to start, unpauses, returns ready promise (play-ready
promise? start-ready promise?)
i.e. seek + resume();
finish() - seeks to end, unpauses, returns ready promise?
i.e. seek + resume();
the unpausing is important because it ensures calling finish()
results in the play state becoming finished
Issue: Should finish() unpause? Some people think it shouldn't.
Two more operations built on top of that:
play() - seeks if finished/idle, unpauses, returns finished promise
i.e. seek + resume()
reverse() - flips playbackRate; then does play()
After discussion, the set of operations seems reasonable. The only
contentious part was whether finish() should unpause. Agreed to make it
unpause for now but add an issue about this.
Discussed whether these methods should return promises or not, and, if
they do, should there be one ready promise or more? For example, if you
call play() and get back a promise, but call pause() before the play()
takes effect (i.e. before rendering the first frame) should the
originally returned promise reject? Or should it wait until the pause()
has completed and then resolve normally?
Shane and Doug to think about this more.
3. RENAMING TIME FRACTION TO PROGRESS SOMETHING?
To match GSAP and other common usage
- Probably more intuitive
4. ANIMATION END BEHAVIOR
=
See: https://lists.w3.org/Archives/Public/public-fx/2015JanMar/0048.html
Animation end behavior:
- Shane to send proposal to list next week for triggered fill
5. NAMING
=
Some resistance to GroupEffect
Alternatives:
GroupedEffect
EffectGroup
CompositeEffect?
ComposedEffect?
CombinedEffect?
MultiEffect?
Also, instead of KeyframeEffect some other suggestions have been:
PropertyEffect
TweenEffect
Looking at other APIs
QML:
Animation
ParallelAnimation
SequenceAnimation
PropertyAnimation
PauseAnimation
PropertyAction
ScriptAction
CA
CAAnimation
CAGroupAnimation
CAPropertyAnimation
CAKeyframeAnimation
Android
Animator
AnimatorSet
ValueAnimator
MathBox
Animator
Animation
After much discussion, agreed KeyframeEffect is probably best. Not sure
what to call groups, probably GroupEffect and SequenceEffect but we
don't need to lock this down until level 2.
6. LIST INTERFACES
==
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23682
interface Animatable {
readonly attribute FrozenArrayAnimation animations;
}
Proposal for keyframes (in order to support sharing):
- define separate getter / setter for the 'frames' attribute
- getter returns a KeyframeList object which is basically an iterable
wrapper for a list of keyframes that is
Re: [web-animations] wrong formatting of scaled active time definition
On 2014/12/17 15:09, Сергей Грехов wrote: Hi All, Format of scaled active time definition section is wrong. Seems there should be ... + start_offset. Please see attached image. Fixed in: https://github.com/w3c/web-animations/commit/545af4361215de519460f46c7a46fa94ed2da9f6 Thanks.
[web-animations] Web Animations minutes, 18 Dec 2014
Web Animations minutes, 18 Dec 2014 Present: Doug, Shane, Brian Archived etherpad: https://web-animations.etherpad.mozilla.org/ep/pad/view/ro.92487irtSfEow/rev.28977 Agenda: 1. Should we call it timingFunction instead of easing? 2. How are the CSS integration specs coming along? 3. Setting the currentTime / playbackRate of AnimationTimeline 4. Distance when used values cannot be calculated 5. Adding AnimationPlayer.start() and returning Promises 6. Renaming AnimationPlayer.source to AnimationPlayer.animation? 1. SHOULD WE CALL IT timingFunction INSTEAD OF easing? == Last time we ended this discussion with: Shane to suggest to CSS WG they add aliases Shane to coordinate with Tab / Paul Irish / someone to collect data from developers about their preference: consistent naming or short naming To summarise the naming differences: * animation-timing-function vs easing * animation-iteration-count vs iterations * animation-fill-mode vs fill (this one might be ok because SVG uses 'fill') Shane/Doug to chase up dev-rel guys to get the data 2. HOW ARE THE CSS INTEGRATION SPECS COMING ALONG? == Some discussion about what the spec should hold. Suggestion: take current spec text, stick previous draft of how integration works on the end then gradually smooth the two out. Q: Is shipping getAnimationPlayers blocked on this spec? Yes. But we could consider a filter if we really have to (i.e. don't return CSS Animation / Transition objects until that spec stabilizes). Discussed the mechanics of splitting the spec into two levels. Brian is hoping to do this in January. Discussed transition-delay, is it the same as backwards fill? Needs further discussion. 3. SETTING THE currentTime / playbackRate OF AnimationTimeline == This is useful for testing / devtools. Some concern about exposing it to Web content. Authors may be tempted to using this for playback control when normally they should use players for this. Why? Because manipulating the timeline will affect *all* animations on the page including any seemingly innocent transitions used as UI flourishes. In particular we don't want authors pausing the global timeline otherwise all of a sudden transitions etc. don't work and their whole app breaks down unexpectedly. How to make obvious to authors the global impact of their actions if we allow this? Some suggestions: Only make these properties available for timelines other than the document timeline. Currently browsers can implement this as a privileged API. We can investigate exposing it to Web content in level 2. Would be good if such privileged APIs could be exposed for cross-browser testing. 4. DISTANCE WHEN USED VALUES CANNOT BE CALCULATED = From the mailing list: http://lists.w3.org/Archives/Public/public-fx/2014OctDec/0119.html If you can't calculate a used value for any of the paced property values, it falls back to distribute for all pairs of values. 5. ADDING AnimationPlayer.start() AND RETURNING PROMISES While implementing AnimationPlayer.ready I (Brian) went over why AnimationPlayer.play() doesn't return the ready promise (Answer: because authors might assume it returns a promise that resolves when the animation finishes). Cameron suggested perhaps we could do: AnimationPlayer.start() [returns ready promise], and AnimationPlayer.play() [returns finished promise] Shane: This makes sense for start() play() returning the finished promise may encourage chaining of animations. Does start() always set currentTime back to the start? Brian: Or does it simply unpause without the rewinding? Shane likes the idea of composing the different functions from more primitive actions (e.g. reverse() is just set playbackRate + play()). What if play() could be build up from start() + currentTime adjustment when limited. Shane to talk to some others and get some more feedback about whether play() should return the finished promise or if that will encourage a suboptimal approach to chaining animations [ Brian: Later thought after the meeting: start() sounds like the opposite of finish() which suggests it seeks back to the start. Perhaps resume() is better? ] 6. RENAMING AnimationPlayer.source TO AnimationPlayer.animation? One of Mozilla devs yesterday expressed surprise at the source property and source content concept. He very much expected it would be the animation property and source animation. We named it source because it is supposed to be able to point to groups or media items too. But note that all of them are generically called animation nodes and groups are called animation groups. When we introduce media
Re: [web-animations] please, clarify consequences of changing KeyframeEffect.spacing attribute
Hi Aleksei,
Thanks for your question.
On 2014/12/03 19:38, Aleksei Semenov wrote:
According to the specification,
http://w3c.github.io/web-animations/#dom-keyframeeffect-getframes
spacing keyframes, i.e. attributes computedOffset are calculated in
method KeyframeEffect.getFrames().
Yes, but this procedure is also run even if getFrames is not called. It
is performed before calculating values for a keyframe animation effect:
Before calculating animation values from a keyframe animation effect,
an absolute value must be computed for the keyframe offset of each
keyframe with a null offset.[1]
The calculation algorithm depends on KeyframeEffect.spacing value.
So if KeyframeEffect.spacing is changed, next call to
KeyframeEffect.getFrames() returns different result.
Correct.
For example,
var keyframes = [{top: '10px'}, {top: '30px', width: '40px'}, {top:
'100px}, {width: '90px'}];
var effect = new KeyframeEffect(keyframes, 'paced(top)');
var pacedTopFrames = effect.getFrames();
effect.spacing = 'distribute';
var distributeFrames = effect.getFrames();
effect.spacing = 'paced(width)';
var pacedWidthFrames = effect.getFrames();
// pacedTopFrames, distributeFrames, pacedWidthFrames have different
computedOffset values, right?
Correct.
Could you clarify the side effects of such changes?
For example, what happens with currently running animation?
I don't understand why this is any different to other changes to timing
or animation parameters?
For example, if you call setFrames() the animation will update to use
the new keyframes. Likewise, if you change the spacing property the
animation will update to use the new keyframe offsets.
Best regards,
Brian
[1] http://w3c.github.io/web-animations/#spacing-keyframes
Re: [web-animations] Please, clarify Keyframe.composite default value
Hi Aleksei, On 2014/11/07 20:14, Aleksei Semenov wrote: The default value for 'composite' attribute is specified as null ( http://w3c.github.io/web-animations/#dictdef-keyframe ) However if keyframe input contains attribute 'composite' with the value null, the procedure for converting an ECMAScript value to an IDL enumeration type http://www.w3.org/TR/WebIDL/#es-enumeration[WEBIDL] http://w3c.github.io/web-animations/#biblio-webidl will throw TypeError, because null does not belong to CompositeOperation http://w3c.github.io/web-animations/#compositeoperation enum. If I've understood the issue correctly, then I think we should handle null correctly in the procedure for processing keyframe objects. This applies to both 'composite' and 'offset'. I've made a change to that effect: https://github.com/w3c/web-animations/commit/957350a0c2bb140a30030d70bf7a9ddc3dda5cca Please let me know if I've misunderstood the issue. Best regards, Brian
[web-animations] Web Animations minutes, 27 Nov 2014
Web Animations minutes, 27 Nov 2014 Present: Doug, Dirk, Shane, Brian Archived etherpad: https://web-animations.etherpad.mozilla.org/ep/pad/view/ro.92487irtSfEow/rev.28425 Agenda: 1. If you set the startTime on a paused player, what happens? 2. Should the player states be pause-pending and play-pending? 3. Should we call it timingFunction instead of easing? (and other naming issues) 4. Should we call it totalDuration instead of activeDuration? 5. Should we expose playbackRate on AnimationNode without groups? 6. Should AnimationPlayer.play() block on display:none content? 7. Does the polyfill require explicit opt-in for using groups and if not, can we please do that? 8. Should AnimationPlayer.play() return the ready promise? Likewise pause()? 1. IF YOU SET THE STARTTIME ON A PAUSED PLAYER, WHAT HAPPENS? = (Brian) Suggestion: it plays http://lists.w3.org/Archives/Public/public-fx/2014OctDec/0026.html All: playing sounds good This is in the spec now: https://github.com/w3c/web-animations/commit/a34a193749a808750813a8a2227aa25617338261 2. SHOULD THE PLAYER STATES BE PAUSE-PENDING AND PLAY-PENDING? == (Brian) Doug: And reverse-pending... I'm not sure we need these. Brian: I tend to agree Doug: Normally you only care whether the player is pending or not, not why it's pending Shane: If we need to add this later we can add a separate pendingType member Brian: Too many play states makes it hard to work with Leave it as is for now 3. SHOULD WE CALL IT timingFuncion INSTEAD OF easing? == (Brian) Doug: Pretty sure we've had this conversation before. I think we settled on 'easing' because, 1. it's short, 2. it's already used in the industry. Brian: Recently I've received feedback about inconsistent naming for animation e.g. https://twitter.com/rachelnabors/status/520506288401170434 https://twitter.com/rachelnabors/status/520511744461254656 Shane to suggest to CSS WG they add aliases Shane to coordinate with Tab / Paul Irish / someone to collect data from developers about their preference: consistent naming or short naming To summarise the naming differences: * animation-timing-function vs easing * animation-iteration-count vs iterations * animation-fill-mode vs fill (this one might be ok because SVG uses 'fill') Brian to add a note to the spec that infinite repetitions can be specified using Infinity. 4. SHOULD WE CALL IT totalDuration INSTEAD OF activeDuration? = (Brian) Green Sock uses totalDuration. Shane: activeDuration = iterations * duration / playbackRate but totalDuration seems like it should be: totalDuration = activeDuration + startDelay + endDelay Could replace activeDuration with totalDuration and update meaning, or add totalDuration as well. Brian: I'm inclined not to add it until we see concrete use cases. We only have activeDuration because the TAG indicated that the results of calculations should be exposed. Shane: but this is also an important concept in the spec - it's used to determine the activeDuration of containers. Brian: let's not add it or change it for now 5. SHOULD WE EXPOSE playbackRate ON AnimationNode WITHOUT GROUPS? = (Brian) Brian: playbackRate is on both AnimationPlayer and AnimationNode. It's mostly used on AnimationNode for groups, but until we have groups it seems unnecessary to have it on AnimationNode as well. All: yes, let's defer AnimationNode.timing.playbackRate until we have groups. 6. SHOULD AnimationPlayer.play() BLOCK ON display:none CONTENT? === (Brian) Doug: Don't understand the question completely. But I suspect, no. Is this a CSS integration issue? Some thoughts. 1. Animations can have a null target, and still play. 2. An effect callback may not care. Brian: Agreed Shane: It would be weird if an animation with a null target played but an animation targetting something in a display:none subtree didn't. 7. DOES THE POLYFILL REQUIRE EXPLICIT OPT-IN FOR USING GROUPS? == (Brian) Brian: and if not, can we please do that? Groups are likely to change and I'd rather we didn't have to support a lot of legacy content. Doug: Yes, there are now different targets for what should be web-animations-1, and things which are further out. See: https://github.com/web-animations/web-animations-js#different-build-targets 8. SHOULD AnimationPlayer.play() RETURN THE READY PROMISE? LIKEWISE pause()? (Brian) We decided Element.animate returns the player, but is there any reason Animation.play doesn't return the ready promise?
