Brief discussion of CSS integration — should CSS have the following properties:
② if so, should it be possible to revert a CSS-derived animation back to its original, CSS-only state?
Yes to ① and ② means we need _some form_ of timing sharing (or at least part of it). It’s possible we can just expose this through CSS integration rather than as part of the full Web Animations spec. It’s also possible to accept ① and not ② for now. Whether either of these possibilities is desirable is a matter for discussion.
➙ Remainder of discussion regarding the Timing object and sharing deferred to Web Animations F2F in Sydney 11 – 15 Feb
4. INTERPOLATION MODES
Just a curiousity, if we wanted to support, say, interpolation of colours in HSL space as well, where would we hang that off the API?
There’s two parts this:
① automatic rules for interpolating between any two of a given multi-specced value type (color, length, transform, etc.)
② manual specification of rule choice to provide for specific effects
Doug: Similar to this, we might want to support requesting non-numeric interpolation (just snapping to the closer keyframe) for types that are normally interpolable.
This fits under point ②.
Brian: This is similar to SVG’s calcMode attribute
Shane: Looks like we can support Doug’s request using per-keyframe timing functions that are steps at 0.5.
➙ Agreed it doesn’t look like ② is needed for version 1 and that we can add this functionality to the API later if it proves necessary (e.g. by attaching an Interpolator to AnimationEffect that subclasses call out to). Until then, authors can use CustomAnimationEffect to produce specialised interpolation.
One case to bear in mind is SVG’s color-interpolation property:
Most support custom functions. We are concerned about calling out to script during a sample for this. Perhaps we can accommodate timing functions that aren’t pre-defined by simple linear interpolation?
Proposal: spin Timing Functions off as a seperate specification. Ship v1 of Web Animations with just enough timing functions for CSS and SVG support.
Seems to be agreement on this. Done. We’ll keep the basic timing functions inside the Web Animations specification for now, until Timing Functions reaches maturity.
6. MULTIPLE TARGET ELEMENTS
A while ago we decided that in the future we probably want Animation.targetElement to be able to target a list of elements in the future and so we should rename it to 'target'. That's fine, but it probably deserves a bit more thought. For example, *if* we do that, how could you cancel all animations that apply to element A without having side effects?
Maybe we should define cancelling in terms of removing an element from the target property of all animations? And is there are use case for being able to say "cancel all animations targetting A but keep their current value (i.e. freeze them)"? Or "cancel all animations targetting A but first fast-forward to the end"? (A number of APIs have a "finish" method for this)?
Anyway, this doesn't need to block FPWD but I'm just flagging it as an issue for now.
Another related issue, is *if* we allow target to refer to multiple elements, this might influence the way we map SVG to Web Animations.
For example, if version 1 of Web Animations Core only supports a single target BUT version 1 of Web Animations SVG Integration allows <animate select=".cloud" ... /> (and this is the current state of play), then SVGAnimationElement.getActiveAnimations() would probably return one Animation per matched target.
However, once target can support multiple elements it would be far more natural to return one animation with multiple targets but we would be unable to do this if content already expects one per animation. Then, of course, if <animate select=".cloud"> was defined such that when a newly matching element was found it started from the beginning, then in that case, the one animation per target would make sense.
One option might be to simply delay <animate select=".cloud"> until the API catches up.
Also, how does event dispatch work with multiple targets? What is the propagation chain?
Shane’s proposal: templates make much more sense because they:
① allow cancellation to be more logical
② allow assemblages to be targeted by animation groups