Re: [css-animations] Initial summary of outstanding issues

Hi,

We had an informal discussion about these issues yesterday in the CSS WG
face-to-face so I'm following up with the outcomes below.

On 2015/10/27 12:13, Brian Birtles wrote:
 > 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

The Blink Web Animations & CSS Animations implementations do G-β.

Conclusion: This seems fine to spec. There were some issues here:
https://github.com/w3c/csswg-drafts/pull/41.

They probably won't prevent speccing though.


 > (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

Fix spec to make animation-delay live.


 > 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

After discussion, we decided this was not needed and Apple and Google
agreed to remove their implementations of this (at least for Web
content).


 > 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

This is at-risk because currently only Gecko implements it. It should
remain at-risk until there is another implementation of this.


 > 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

Dean: This is (probably) used to determine how many iterations have
happened.

Brian: It believe I found libraries using this member for feature
detection so it may be difficult to remove.

I will do further research to see if this member can be dropped.


 > 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/ 


After discussion, we decided to spec the current Gecko behavior, i.e.
(a).


 > 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

This is a level 2 feature that should be added to a level 2 draft (at
least as an issue for now).

Adding an identifier to the name would also solve the previous issue
with regards to knowing which animation to match.


 > 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.

After discussion, we agreed that that animation-timing-function doesn't
cascade between keyframes.

More specifically, that a lack of animation-timing-function in
a keyframe is an affirmative request to use the value from the element,
not just a lack of declaration.


 > (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

Yes, expand shorthands first.


 > 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

Agreed this is ok but need to be careful that properties can list
multiple types (but it seems there's only one legacy example of this
- line-height) that don't interact with each other, in addition to being
able to list a compound type like "length, percentage, and calc()"

Animation Type sounds good.
Should mass-edit specs to fix.
Some specs (images, transforms, shadow) already have custom 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

Also,

* https://github.com/w3c/csswg-drafts/pull/42 (with discussion in 41;
   I think something there was actually pointing at some missing text)
* Go through public-fx and www-style and look for more questions
   - https://github.com/dbaron/gather-doc-email may be useful
* Check that everything in
   https://lists.w3.org/Archives/Public/www-style/2012Nov/0261.html was
   edited (although the non-interpolable values needs to be done in
   transitions)


Best regards,

Brian

Received on Wednesday, 28 October 2015 05:44:49 UTC