[css-animations] Initial summary of outstanding issues

Hi,

I'd like to understand what are the outstanding issues for CSS
Animations. I've drawn up the following list for our discussion at TPAC.
If you'd like to follow up on any of these topics, please rename the
subject of the email when you do so.

Sorry for the last minute notice. I should have sent these issues to the
list well in advance but the chance to discuss these at TPAC came about
unexpectedly.


1. Liveness
-----------

Two issues here:

(a) Base value liveness was resolved[1] to use the G-β variant from
     [2].

   Last I can see, Sylvain was requesting help writing spec text for
   this.[3]

   I'll note that the original proposal came with the caveat:

   "I would not want to commit to (E), (F), or (G) without somebody
   having implementation experience handling both the repeating
   animations issue and handling sending such animations to be run on the
   compositor."[1]

   We've yet to implement this in Gecko[4] so I'm reluctant go ahead with
   specifying this part just yet unless anyone else has done so.

   [1] https://lists.w3.org/Archives/Public/www-style/2014Oct/0290.html
   [2] https://lists.w3.org/Archives/Public/www-style/2014Aug/0132.html
   [3] https://lists.w3.org/Archives/Public/www-style/2014Oct/0393.html
   [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1064915

(b) Liveness of animation-* properties

   Proposal was to make everything adjustable but to fix the start time
   once it is resolved.[1]

   One question was about whether the start time means the beginning or
   the end of the delay phase.[2] David Baron's suggestion was that it is
   the start of the delay phase. This allows adjusting the
   animation-delay after the animation is started and matches the Web
   Animations model where the delay is measured from the start time.

   When this was specced, however, it was taken to be the end of the
   delay, that is, changes to the animation-delay are ignored once the
   animation has started.[4] I think this is a bad idea since it means
   animations behave differently depending on whether or not a style
   flush was triggered before the animation-delay was changed.[5]

   This came up recently because people are updating the delay as a way
   of seeking an animation for debugging.[6] This works in Blink and
   Gecko but not Webkit. I'd like to update the spec to remove the
   reference to snapshotting the animation-delay.

   Event dispatch wording might need rework but we have a generalized
   definition of that in CSS Animations 2 that we can probably use and
   that agrees with the approach Tab outlined.[3]

   [1] https://lists.w3.org/Archives/Public/www-style/2014Sep/0129.html 
(see particularly the clarification in: 
https://lists.w3.org/Archives/Public/www-style/2014Sep/0130.html)
   [2] https://lists.w3.org/Archives/Public/www-style/2014Sep/0131.html
   [3] https://drafts.csswg.org/css-animations-2/#event-dispatch
   [4] 
https://github.com/w3c/csswg-drafts/commit/84f853d8b2c54ba8244de95b2e3aa8e8f337ad18 
based on https://lists.w3.org/Archives/Public/www-style/2014Oct/0309.html
   [5] https://lists.w3.org/Archives/Public/www-style/2014Oct/0318.html
   [6] https://css-tricks.com/debugging-css-keyframe-animations/ as 
brought up here: 
https://lists.w3.org/Archives/Public/www-style/2015Aug/0106.html


2. onanimation* Event Handlers
------------------------------

Blink (and WebKit?) has these.[1] Ok to spec them?
I've prepared draft spec text (animation events only, so far).[2]

[1] https://chromiumcodereview.appspot.com/23583032/
[2] https://github.com/w3c/csswg-drafts/compare/animation-event-handlers


3. pseudoElement Member
-----------------------

The pseudoElement of the AnimationEvent interface is marked at-risk.[1]
Why is this? Are we hoping to use the CSSPseudoElement interface
instead?

[1] https://drafts.csswg.org/css-animations/#status


4. elapsedTime Member
---------------------

This definition needs clarification but it's hard to know what the
intended behavior is. Are there any use cases for this?[1]

It's useless for lining up Javascript animations with CSS animations
since it represents the ideal elapsed time, not the actual elapsed time.
(That is, if an animation repeats after 3s but the first animation frame
after that point is after 3.05s, we'll still report an elapsedTime of 3,
not 3.05.) So, what is it good for?

[1] https://lists.w3.org/Archives/Public/www-style/2015Sep/0304.html


5. Handling of multiple overlapping animation names
---------------------------------------------------

If I have:

   animation: abc 5s;

And, while 'abc' is running on 'elem', I do:

   elem.style.animationName = 'abc, abc';

Will the existing animation be mapped to the animation at the end of the
list or the one at the start?

This will be observable since you'll either see:

   (a) The original animation continue to the end, then the last part of
       the new animation run (assuming no forwards fill), or
   (b) A new animation immediately start and run to completion.

If you match animation names from the end of the list (i.e. effectively
prepend the new animation), you'll get (a).

If you match animation names from the start of the list (i.e.
effectively append the new animation), you'll get (b).

In Gecko we currently do (a). The reasoning being that, "since later
animations in the list override earlier ones, the last occurrence is
most likely (though not certain, if it's not currently running/filling)
to be the one that's actually influencing state"[1]

Testing with this pen: http://codepen.io/anon/pen/bVvJBO , Blink and
Edge appear to ignore multiple references to the same animation.

Note that supporting multiple references to the same animation name
lets you restart animations on :hover (but doesn't let you restart
again when leaving the :hover state).[2]

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1037316#c4
[2] 
http://justmarkup.com/log/2015/01/26/restart-css-animation-using-css-to-trigger-a-reflow/


6. Restarting with the same name
--------------------------------

Lea Verou was wondering how we can start and restart animations when we
transition in *and* *out* of :hover.[1]

Is it worth adding some garbage to animation-name syntax for triggering
animations?

https://lists.w3.org/Archives/Public/www-style/2015Oct/0174.html


7. Keyframe handling
--------------------

Tab provided a revised description of how @keyframes rules combine,
specifically with regard to how animation-timing-function values are
applied.[1] It seems reasonable to me so I'd like to try and spec it.

A couple of concerns, however:

(a) How animation-timing-functions inherit.

   e.g.

   @keyframes abc {
     to { left: 200px, animation-timing-function: linear }
     to { left: 300px }
   }

   Will animate to 300px with the computed value of the
   animation-timing-function on the target element.

(b) Shorthands.

   For the step, "Divide the list of transition endpoints into a number
   of independent lists according to the property associated with the
   endpoint, maintaining the relative order", is this supposed to work
   after expanding longhands?

[1] https://lists.w3.org/Archives/Public/www-style/2015Jul/0391.html


8. Specifying animation types
-----------------------------

We've talked about replacing the "Animatable" line in property
definition tables with "Interpolable".[1]

In Web Animations, everything is animatable unless animation is
explicitly prohibited (e.g. animation-* properties). The default type of
animation is "as string" which is basically discrete interpolation such
that the value changes at the midpoint.

Web Animations lets you do more than just interpolation but also
addition and accumulation.[2] For each property we can animate, we need
to define what each of those three things mean. Web Animations calls
that set of definitions the "animation behavior".[3] I think "animation
type" might be a better name, however.

This is different to the CSS type since you might have two different
properties with <number> type but where one is allowed to add and the
other isn't.

Web Animations provides a few pre-defined "animation types (behaviors)"
such as "Animatable as string", or "Animatable as real number". Specs
can use one of these or define their own.

Perhaps the property definition table should say, "Animation type:
string"?

[1] https://lists.w3.org/Archives/Public/www-style/2015May/0256.html
[2] http://w3c.github.io/web-animations/#procedures-for-animating-properties
[3] http://w3c.github.io/web-animations/#animation-behavior


9. Other issues?
----------------

* Are the shorthand issues resolved?[1][2]
* Possible issue around shorthands[3]
* Others?

[1] https://lists.w3.org/Archives/Public/www-style/2014Dec/0340.html
[2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=28053
[3] https://lists.w3.org/Archives/Public/www-style/2011Oct/0834.html


Best regards,

Brian

Received on Tuesday, 27 October 2015 03:13:30 UTC