W3C home > Mailing lists > Public > www-style@w3.org > February 2013

[CSSWG] Minutes Tucson F2F 2013-02-05 Tue AM II: Transitions and Animations, Tokyo F2F

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 14 Feb 2013 20:15:05 -0800
Message-ID: <511DB649.9070905@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Transitions and Animations

   - RESOLVED: Publish updated WD of Transitions with those edits
   - Discussed editorial work for animatability propdef lines
   - Discussed interaction of transitions and animations, cascade

Tokyo F2F

   - RESOLVED: June 5-7 at Mozilla Japan in Tokyo

====== Full minutes below ======


   dbaron: Follow-up from yesterday
   dbaron: We agreed on a whole bunch of edits
   dbaron: Want to publish a WD with those edits, most of which but not
           all of which are done,
   RESOLVED: Publish updated WD of Transitions with those edits
   ACTION dbaron: edit publish Transitions
   <trackbot> Created ACTION-534

   dbaron: Things are done, except bits wrt moving to other specs
   dbaron: In general, should I write them and check them in, or send mail
           to editors with patches
   jdaggett: I want a patch
   TabAtkins, fantasai: Just check them in
   fantasai: Any editor's other than jdaggett want a patch?
   szilles: Which specs affected?
   dbaron: High priority are fonts, ui, backgrounds, ...
   dbaron: Other thing is, I've made some slight editorial changes
   dbaron: table that describes how properties are animatable now looks
           the way I want animatable lines work
   TabAtkins: Can't do just "Animatable: yes" for simple things?
   dbaron: Right
   TabAtkins: :(

Cascade of Animations and Transitions
+dino (remote)
+hober (remote)

   smfr: In august F2F there was a resolution that Transitions happen
         last in the Cascade
   smfr: This related to !important rules overriding animations
   dbaron: We did want !important rules to override animations, which
           meant animations not at the top
   dbaron: Also how transitions start as a function of computed style
           changes, requires them to be on top of everything else that
           affects computed style
   dino: In my mind I agree that !important rules should override animations
   <smfr> link to previous discussion: (see 16:42):

   dino: [something about stopping animations]
   <smfr> dino suggesting that the way to override animations is
          animation-name: none !important;
   dbaron: But that would stop all animations.
   dbaron: If a user needs high contrast colors, but motion is fine, if
           they try to enforce high contrast they lose animations
   dino: Right.
   dino: Inconsistency that we discussed a few months ago
   dino: Would be nice to set it up so that force color overriding animation
   dino: Seems like we need some new special rule for cascade so you can
         do both what you want and in general case override transitions

   dino: red to blue animation infinitely
   dino: some other rule applies temporarily trigger a transition that
         overrides the animation
   dino: So suppose you have red to blue animation
   dino: Have a transition rule on color, color transitions over 1s
   dino: :hover rule changes color to green, but it's not !important
   dino: It would change the color to green
   dino: which interrupts the animation
   dbaron: It would only interrupt if the color to green is a change that
           overrides the animation
   dino: Transitions apply last
   dino: Yes, but transition only happens if there's a computed value
         change to trigger it
   dbaron: So, in our model, when we're deciding when to start transitions
   dbaron: We're looking at a computed style that already has animation
   dino: So technically would start a transition very often
   dbaron getting confused now
   dbaron: I know we don't start transitions as a result of changes from
   dbaron: We have a concept of style with/without animations
   smfr: You would only show a transition when there would be a visible
         change that isn't caused by the animation
   smfr: So if !important rule makes it yellow, you start a transition
   smfr: What's your starting color?
   dbaron: Think it's the currently animating color
   fantasai: Think that's what it should be

   smfr: More pragmatic point is, WebKit we don't do that. Animations are
         applied last, overriding !important rules
   smfr: So for next year or two we'll have different implementations
   smfr: How do we deal with that?
   dbaron: From security perspective, bunch of !important rules in our
           UA style sheet, and they must take effect.
   fantasai: I think honoring the !important rules is the right thing for
             the user.
   [lots of discussion that wasn't minuted]
   fantasai: [stuff mostly about how there seems to be no new info, and
              we're just repeating the discussion we had last time,
              which fantasai does not want to minute again, personally]

   szilles: Seems like 2 issues here: whether !important should win,
            and whether transitions or animations win
   molly: Wrt a11y and user, animations and transitions are 2 aspects
          of CSS where a11y does come into play, and having !important,
          don't have an opinion on transitions vs. animations, but should
          not interrupt pattern of allowing users !important over that stuff
   szilles: If I'm doing an animation, what does it mean for the !important
            rule to take effect but not stop the animations
   fantasai: It means the animation continues, but that value does not change.
   plinss: Wrt transitions, it's a red herring. If !important rule overrides,
           and there's a transition to that state, shouldn't affect whether
           or not !important overrides the statement.
   smfr: In WebKit in theory we would like !important to override, but it's
         not our current implementation

   plinss: Nobody's disagreeing
   dino: Maybe explain the point again from last time
   dino: Completely agree that !important style rule should override an
   dino: But don't think transitions should apply after animations, think
         it causes inconsistency in the model
   dbaron: Could imagine a model where cascade for animations sort of
           operates instead of on the actual value on a dummy value that
           says "the value of this comes from this animation"
   dbaron: And then if that wins in the cascade, then you use the animation
   dbaron: In that sort of model, can see animation overriding the transitions
   dbaron: I know how to do it in our implementation, don't know how to
           specify it in CSS specs
   TabAtkins doesn't understand what was just said; fantasai neither
   fantasai: Isn't that what transitions is already doing?
   fantasai: I don't understand this assertion that transitions should
             lose to animations.
   dbaron: If you've specified an animation, that should win over transition
           between static value

   fantasai: Suppose you have two states, State A and State B.
   fantasai: In State A, you are running animation Q
   fantasai: And in State B, animation Q does not run
   fantasai: Why would you not want a smooth transition from State A to
             whatever State B wants?
   dbaron: Do you want a transition from the animated state of A, or the
           non-animated state of A.
   fantasai: whatever I'm seeing at that moment
   <TabAtkins> .foo { color: yellow; animation: go-from-red-to-blue 1s infinite; }
   <dino> now change color to green
   <TabAtkins> .foo:hover { color: green; }
   <dino> in both cases you see animation
   <TabAtkins> .foo { transition: color 1s; }
   plinss: Nothing triggers a transition, because nothing changes
   plinss: The animation is still overriding the color
   plinss: The color of the element has not change.
   dino: If there was a transition on color, why would we expect the
         yellow-to-green transition?
   plinss, fantasai: Nobody expects that

   dbaron: I think we're going around in circles, yet I don't think there
           is any disagreement over the desired results
   fantasai: So, suppose in the :hover state, we say animation: none;
             so that it is in fact green
   fantasai: Dean is asserting that you won't see the transition, it
            just snaps to green
   fantasai: And peter and I are saying it should transition to green
             from whatever color it was starting at.

   <dbaron> I think we agree that (a) we want !important rules to override
            animations and (b) we want animations to override transitions
   dbaron: I don't care what happens in fantasai's case, should be whatever's
           easiest that gets us a and b

   discussion of where to start
   dbaron: Are you starting from base state of the animation state, the
           current state of the animation, or the dynamic state of the
   plinss and fantasai are saying the 2nd option
   plinss: When you trigger :hover, the animation has ended
   plinss: you take the state of the animation at that point, and then
           take that as the starting point and go from there to the
           :hover state
   dbaron: I think use cases for these features are mostly orthogonal,
           and interaction should be what makes sense
   <sylvaing> +1 to david's orthogonality point. the demand to solve this
              is 100% spec completeness afaik.
   <TabAtkins> Which is half of why we do anything in this group anyway.
   <sylvaing> to the risk of being outrageous I'd even propose to keep this
              undefined in this level.

   dbaron: Four options
   dbaron: Suppose you have

     p { margin-top: 50px;
         transition: margin-top 2s linear;
         animation: bounce 1s infinite alternate }
     @keyframes bounce { from { margin-top: 100px } to { margin-top: 150px } }
     p:hover { margin-top: 0; }
   dbaron draws a graph:
     150px 100px 50px 0px along y axis
     x axis represents time
   hover is halfway along time: state change marked as a boundary
   dbaron draws the base-state of the margin at 50px straight through to
          :hover line
   dbaron draws the animated state as a zig-zag from 100px to 150px sloping up,
          down, up, then halfway down before hitting hover
   dbaron adds
      :hover { animation: none; }
   plinss: Does anyone disagree that without the animation: none rule,
           it would just continue to animate?
   Everyone agrees that continuing to animate is what we want

   Alternate options for creating the same problematic situation:
     /* option 1 */ p:hover { margin-top: 0; animation: none }
     /* option 2 */ p:hover { margin-top: 0 ! important }

   dbaron draws a dotted line representing this continuation of the zigzag
   dbaron draws 4 options
     1. If from or to value comes from animation, there's no transition.
        Just instant change.
        (draws line dropping straight to zero at hover)
     2. The transition ignores the animation completely. You transition
        from base state (50px) to zero.
        (draws line dropping from 50px at hover to zero after 2s)
     3. Take from where the animation left off to where the :hover state is
        (draws line from partway through the zag at :hover down to zero at 2s)
     4. Transition, interpolating between the dynamic state of the animation
        and zero
       (draws line that zigzags slightly from the :hover point on the animation
        converging to zero)
   <glazou> http://lockerz.com/s/281620122
   * sylvaing must say this is a pretty awesome graph

   <dino> I would be quite scared if we couldn't come to agreement on this
          situation. It's the !important one that's tricky.
   plinss: 4 should never happen, because the animation is no longer running
   dbaron: Alternate end state, p:hover { margin-top: 0 !important; }

   dbaron: We have zero models that explains all the other stuff we want,
           so let's figure out a model that gets us everything else we want
           and then see what falls out of that
   plinss: Just before you hovered, there was no animation, but a transition
           running from some previous state
   plinss: Suppose there was no animation, base state is margin-top 50,
           but just before that you were in some other state, and there's
           a transition running from that state to the 50px
   plinss: Now you start the :hover.
   plinss: Where are you transitioning from?
   dbaron: That's the open issue Tab has an action item to write a JS
           simulation for
   plinss: Think the answer to that should inform the answer to this
   dbaron: A change caused by an animation does not trigger a transition
   dbaron: Not difficult to go from there to, if your before/after state
           is an animation, you don't transition
   plinss: It's *an* answer
   plinss: 2 and 3 both make sense
   <dino> I like what I think dbaron is suggesting. (obviously assumes
          I think what I'm thinking!)
   fantasai: I don't like 2, it jumps

   smfr: 3 is problematic, because, imagine flip this around
   <sylvaing> what happens with #3 when you un-hover?
   smfr: You're trying to hit a moving target
   plinss: If your :hover is applying a different animation, you're trying
           to hit two moving targets
   <sylvaing> suspects answers that mitigate jarring visual discontinuities
              are better for authors but you end up managing 2 or more
              states for the same computed value which is....weird.
   fantasai: I think in the case smfr outlines, you'd look 2s into the
             animation, where am I supposed to be, then transition into that.
   fantasai: That's what's going to get you the smooth transition, which is
             what you want. Otherwise it's jumpy.
   dbaron: If you go from big animation to small animation, you can't pick
           the time that will look right
   dbaron: Because the correct time will depend on the speed you want,
           which can vary depending on the distance you're trying to hit
   smfr: We don't have paced animations
   [discussion of velocity]
   <sylvaing> if an author wants something this sophisticated, i'm not
              sure the current level of Transitions/Animations cuts it.
   dbaron: Then you need distance functions for all your properties.
   plinss: That's a level 4 Transitions feature
   dbaron: Level 5
   <sylvaing> Web Animations Level 6!
   plinss: Yeah. But I think it's an important use case that we should get to
   plinss: The only way you'd get behavior of 4 is if the animation
            continues during the transition period even though you've
            turned it off. It could be rational, but a lot of work
   <sylvaing> agree #4 isn't an option in this case.

   smfr: Have a few high-level comments.
   smfr: Think looking at use cases and desired behavior is good, for
         coming up with correct model
   <sylvaing> +1 to smfr
   smfr: Also for current level of spec, not sure we'll come to agreement.
   smfr: Agree with sylvaing, maybe we should leave this undefined.
   szilles: Problem with that is you can't fix it if there's wide deployment
            of something
   <sylvaing> szilles, I think that's a feature...
   fantasai: What exactly are we proposing to undefine?

   dbaron: I think we need to work on a model that answers the rest of
           the stuff
   dbaron: How we describe how transitions/animations interact with cascade,
           even ignoring this issue.
   dbaron: How do transitions interact with cascade, how do animations
           interact with cascade, ignoring how they interact with each other
   dbaron: Maybe including how they interact with each other in the
           non-boundary case.
   fantasai: You mean, if we remove 'animation: none' from that example
   <dbaron> (i.e., with /* option 3 */ p:hover { margin-top: 0 })
   fantasai: Since we agree the animation should just keep going
   <dbaron> we all agree that
              p { margin-top: 50px;
                  transition: margin-top 2s;
                  animation: bounce 1s infinite alternate }
              @keyframes bounce {
                from { margin-top: 100px }
                to   { margin-top: 150px } }
               p:hover { margin-top: 0 }
            should produce no visible transition (the animation should
            just keep going)

   szilles: If an animation is running and therefore defining the value
            of a property, then using some other mechanism to change the
            value of that property has no effect (regardless of whether
            a transition period was defined).
   szilles: The animation is overriding the value of the property anyway
   szilles: question is interesting, if the animation stops, completes,
            then what's the value of the property?
   szilles: :hover is still there, animation completes
   plinss: When the animation completes, return to the base value of the
   <sylvaing> once animation completes I'd expect the :hover rule to apply
   szilles: If you're in :hover, and animation terminates while you're in
            :hover, whatever cascade says value will be will be the value
   szilles: Question then is, is a transition triggered when the animation

   smfr: Think dean, me, dbaron, anyone else might meet to go through use
   plinss: Think open issue Tab was going to write JS for is important here
   dbaron: I don't think so
   dbaron: That's internal to the transitions model, the reversing behavior
   dbaron: No cascading behavior, not two different models interacting with
           each other

   szilles: Why is interrupting a transition with a transition different
            from interrupting an animation with a transition?
   dbaron: [something about different models]
   szilles: As a user, how is it different?
   dbaron: It's a much more important use case
   dbaron: It's very common to interupt a :hover partway through a transition
   plinss brings up case of animation ending, do you snap to base state
   smfr: Yes. Never transition due to animation
   plinss: So in that case, we shouldn't transition from any other animated
   <sylvaing> we do have a clause saying animating values do not cause
              transitions to start
   plinss: See the logic of it. Not sure users would be happy with that.
   <sylvaing> if people apply both an animation and a transition to something
              I think it's rational to believe they don't expect unanimated
              transitions between the two
   <sylvaing> or other visually janky switching
   szilles: Agree. Think users would like to be able to avoid flashing.
   szilles: question is, is that some new L5 feature we add to handle that
   fantasai: You could have an animation-transition property :)
   szilles: pick a simple solution for this, add something to patch it later

   ACTION dbaron meet with smfr and dino to come up with a proposed model
          for transitions/animations cascading and interaction
   <trackbot> Created ACTION-536

F2F in Tokyo

   <jdaggett> http://wiki.csswg.org/planning/tokyo-2013
       June 2013
   Su Mo Tu We Th Fr Sa
   2  3  4  5  6  7  8
   9 10 11 12 13 14 15
   jdaggett: One complication, SVG wants to co-locate
   jdaggett: Mozilla will sponsor both meetings
   jdaggett: Multiple offers of ppl to host one or the other, but I think
             easier to keep on one site
   jdaggett: Looks like Mozilla Japan will have a new office with room
   jdaggett: So would like to pick dates
   <dbaron> June 5-7 are the proposed dates
   <dbaron> AC meeting is 9-11
   RESOLVED: June 5-7 at Mozilla Japan in Tokyo
   <dino> when is the SVG meeting?
   <jdaggett> dino: svg is discussing that this week
   <jdaggett> dino: on friday i think

<br type="lunch" />
Received on Friday, 15 February 2013 04:15:37 UTC

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