[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 whenever
another (non-animation?) style change occurs.

Shane will follow up on this and send a mail.

Supposing we add two different kinds of fill: "cancel-on-change-fill"
and "permanent-fill", should we expose "permanent-fill" to script? It is
a sort of a footgun but is probably necessary to expose it so that
script can polyfill SMIL, for example.

Also, should the cancelling behavior be per-property or per-animation?
After some discussion, we think it should be per-property.

Q: Would there be any API to detect if a particular property had been
    ignored/cancelled?
A: No.
Q: Isn't that bad?

Some discussion about adding an API for querying per-property metadata 
such as:

i.   Is this property being animated by this effect? Or is it being
      clobbered by something else?
ii.  What is the current contribution of this effect to the property's
      value? -- i.e. its intermediate effect value
iii. Is this property being animated on the compositor? (since UAs may
      do some properties on the compositor and others on the main thread
      within the same animation)

AI: Shane to email public-fx/www-style and draft some specification text
(in a branch) for this feature.


6. CSS ANIMATIONS AND TRANSITIONS SPECS
=======================================

Already a delta spec for CSS Animations level 2:
http://dev.w3.org/csswg/css-animations-2/

There's also http://dev.w3.org/csswg/web-animations-css-integration

Level 2 must haves:

* API mapping
* CSSAnimation / CSSTransition interfaces
* cancel events

Difficult areas to spec:

* overlapping animation names (not really specific to the API)
* play/pause interaction
   Outline here:
 
http://mxr.mozilla.org/mozilla-central/source/layout/style/nsAnimationManager.h?rev=70c5890d9577#94
* dispatch of events in light of seeking

Brian: Keen not to add much/any new stuff or at least to have a stable
        subset we can ship soon. Might we worth investigating a simple
        group mechanism though (see item 9 below).

Shane: I'd like to investigate how to expose additive animation too.

Discussed adding an animation-composite property for this. Seems
feasible.

Interface proposal:

   interface CSSAnimation : Animation {
       readonly attribute DOMString animationName;
   };

   interface CSSKeyframeEffectReadOnly : KeyframeEffectReadOnly {
       readonly attribute CSSKeyframesRule rule;
   };

   interface CSSTransition : Animation {
       readonly attribute DOMString transitionProperty;
   };

 > We will start working on a fork of css-animations-2 then present to
   CSS WG, adding in:
- the interfaces above
- a description of animation-play-state interaction with the API (see
   item 10 below)
- mapping to the API (based on
   http://dev.w3.org/csswg/web-animations-css-integration)
- more generalized event dispatch description to handle seeking,
   reversing etc. (see item 11 below)


7. FILTER FOR CSS VS SCRIPT getAnimations
=========================================

Q: What about adding a filter to getAnimations() to return, say, only
    script-generated animations / only CSS animations?
A: Sounds feasible for a future level (we already mentioned the
    possibility of additional options parameters to getAnimations() in
    item 4)

Q: What would the default be? All animations or just script-generated
    animations?
A: All animations.


8. ANIMATION FINISH EVENT (NAMING) AND BEHAVIOR ON CANCEL
========================================================

Can't call it animationend. What should we call it?

Suggestion, two events:
* finish, and
* cancel

Possible risk with already-implemented finish event in Chrome (it also
fires on cancel). Doug & Shane to check.


9. GROUPING IN CSS
==================
(Brian)

Strawman proposal to get discussion going:

* Add animation-group: <name>, <name>, <name>
* These names match up with the animation-name property
* For each time you have an animation-name with an associated
   animation-group, we look for an existing group in the context and add
   the generated KeyframeEffect to that group
* animation-group-reset: <name>, ... establishes a new instance of the
   group for  that subtree in the same way counter-reset does
* setting animation-duration etc. updates the individual KeyframeEffect
* The only property that affects the shared Animation object is
   animation-play-state which is where it gets tricky.
* Prefer to support a single level GroupEffect initially and later
   extend to SequenceGroups and hierarchies of groups, possibly by
   introducing an @group rule

e.g.

.a {
     animation-name: anim-a;
     animation-duration: 1s;
     animation-group: foo;
}
.b {
     animation-name: anim-b;
     animation-duration: 2s;
     animation-group: foo;
}

Animations anim-a and anim-b will have the same start time regardless of
when the classes get added to the matching elements.

Discussed the possibility of specifying an insertion index as well:

   animation-group-name: group-name index;

Discussed an alternative proposal that introduces group-name. group-name
establishes a group for the subtree rooted by the element; in the
absence of a group-name specifier, the document root will introduce one.

This is essentially animation-group-reset by a different name but is
more conducive to extending with other group properties.

Comparing the two:

A) animation-group-reset:

Advantages:
  - minimal modification, no @group necessary initially
  - matches counter-reset
Disadvantages:
  - no way to specify group timing properties without @group
  - won't ever be able to declaratively modify group timing

B) group-name:

Advantages:
  - no need for @group
  - group creation at a node seems somehow simpler to reason about than
    group resetting (although actually the behavior is the same)
Disadvantages:
  - doesn't match counter-reset
  - have to define a bunch of group timing properties to match animation
    timing properties


Proposal C, animation name can reference @group as well as @keyframe
descriptions; if an @group is referenced then the animation
specification defines a group rather than an animation.

Advantages:
  - less stuff needs to be defined
Disadvantages:
  - need @group definitions from the start
  - really difficult to understand

The big issue is what to do about animation-play-state (the other
animation-* properties are generally ok since they map to the individual
KeyframeEffect objects but animation-play-state maps to the shared
Animation object so we need to resolve how they combine together).

Some possibilities:

* animation-play-state computes to 'slaved' for animations that are part
   of groups. group-play-state is used to toggle the play state of groups.
* If any of the children of an animation group are paused, the shared
   Animation object is paused but this isn't reflected in style in any
   way.
* Others?


10. INTERACTION OF animation-play-state AND THE API
===================================================

Two proposals:

A: Sticky pause
* As implemented in Gecko:
 
http://mxr.mozilla.org/mozilla-central/source/layout/style/nsAnimationManager.h?rev=70c5890d9577#94
* An animation's natural state is running. Pausing takes it out of that
   state.
* A call to pause() on a particular element sticks until play() is
   called which returns the element to its natural state.
* So long as you have a sticky action, you need a way to unstick it
   hence pause() is sticky but play() is not.
* play() will trigger an animation paused by style but won't override
   any subsequent changes to style.
* pause() acts as a piece of local state overriding any global state
* useful for devtools to be able to pause an animation and have that
   continue to apply regardless of any changes to style

B: Latest action wins
* If you call pause() / play() then change style back and forth, the
   style changes will take affect
* More symmetrical
* Less power to script

 > Decided A is ok


11. GENERALIZED EVENT DISPATCH
==============================

CSS event dispatch assumes time keeps progressing forwards. Once we
introduce Web Animations there is the possibility of seeking and playing
backwards so we need a more generalized approach to event dispatch.

Proposed approach (as implemented at least in Gecko):

* Define the "active range" as the period from the startTime to the end
   of active interval since animationstart fires at beginning of delay
   phase
* At a moment an animation can be in one of three states
   - left-side of the "active range"
   - inside the "active range"
   - right-side of the "active range"
* Before updating the time (due to seeking or regular sampling) record
   the current state
* After updating the time compare the new state with the previous state
   and dispatch events as follows:
   - inside -> outside = animationend
   - outside -> inside = animationstart
   - outside -> outside but with a change in side =
     animationstart + animationend
   (- inside -> inside with a change in current iteration
     = animationiteration)
* the exact definitions depend on the playback rate but that's the rough
   outline


Topics for next time:
* Custom effects
* Specing frames/sampling

Received on Tuesday, 26 May 2015 01:55:39 UTC