W3C home > Mailing lists > Public > www-style@w3.org > November 2015

[CSSWG] Minutes Sapporo F2F 2015-10-27 Part V: Animations [css-animations]

From: Dael Jackson <daelcss@gmail.com>
Date: Mon, 23 Nov 2015 20:16:37 -0500
Message-ID: <CADhPm3sum-vUJ68Dyfusr1h8_fLXYPyuc5jisJgfKbP7VWCBvA@mail.gmail.com>
To: www-style@w3.org
Animations
----------

  - Reaffirmed that for liveness, the right approach was:
      - base values are interpolated values from all animations on
          this element and on all elements on which its computed
          values depend.
      - base values are dynamic (i.e., if the expected value at a
          future time changes the running animation changes to match)
  - Remove the *onanimation Event Handlers because they're not needed.
  - Leave pseudoElement of the AnimationEvent interface at risk - it
      only has one implementation.
  - The usage of elapsedTime Member will be examined to see if it
      can be dropped.
  - The current Gecko behavior will be specced for handling of
      multiple overlapping animation names.
  - Having multiple identifiers per @keyframes rule is a level 2
      feature.
  - A bunch of people seem to agree 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.
  - Animation Type seemed like a good idea and there should be a
      mass spec-edit to make the appropriate changes.
  - There needs to be a comprehensive pass through of mailings lists
      and github to make sure all issues, especially with
      shorthands, were captured and addressed.

===== FULL MINUTES BELOW ======

  [This discussion didn't occur in IRC, but instead used an etherpad
      (linked below) for the conversation. The text below the IRC
      conversation is copied from the etherpad. Also, as it is an
      etherpad, there were multiple authors, not a designated scribe]

  <astearns> reconvening to talk about css-animations issues, if we
             can get a quorum to come back to the room
  <birtles> https://lists.w3.org/Archives/Public/www-style/2015Oct/0222.html
  <birtles> https://public.etherpad-mozilla.org/p/css-animations-issues-list
  <astearns> (notes will be taken on the etherpad as we go)
  <dbaron> G was relative to
http://lists.w3.org/Archives/Public/www-style/2014Aug/0132.html
  <dbaron> https://github.com/w3c/csswg-drafts/pull/41
  <dbaron> https://lists.w3.org/Archives/Public/www-style/2014Apr/0373.html

Animation
=========

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

    Conclusion: Fix spec to make animation-delay live

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

  Blink and WebKit have 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

  Conclusion: Not needed, should remove
https://drafts.csswg.org/css-animations/#event-handlers-on-elements-document-objects-and-window-objects

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

  Conclusion: At risk because currently only Gecko implements it.

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: Libraries using for feature detection so maybe can't remove.

  Conclusion: Look at usage to see if it 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/

  Conclusion: spec the current Gecko behavior


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 something to animation-name syntax for
    triggering animations?

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

  Conclusion: Level 2 feature
  Conclusion: Add to level 2 draft (at least add an issue)

  Adding an identifier would also solve the previous issue with
    regards to 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.

  (i.e. this behaves the same as:
    @keyframes abc {
      to { left: 300px }
    }
  )

  Conclusion: Sounds like a bunch of us seem to agree 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 shorthands?

  Conclusion: yes, expand shorthands first

  [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"?

  Conclusions:
    > Just 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

  [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?

  Conclusions:
    - 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)

  [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
Received on Tuesday, 24 November 2015 01:17:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:58 UTC