W3C home > Mailing lists > Public > www-style@w3.org > October 2014

[CSSWG] Minutes Sophia-Antipolis F2F 2014-09-09 Part IV: Animations

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 15 Oct 2014 14:10:22 -0400
Message-ID: <CADhPm3uWnqG+cuEXqEkH3pmxNBPaUCeTas=7mRE7sbfrpN1j3Q@mail.gmail.com>
To: www-style@w3.org
Animations
----------

  - sgalineau outlined the remaining issue about how to resolve
       properties that depend on a value from a different property.
       The options for the behavior were outlined in an e-mail from
       dbaron available here:
       http://lists.w3.org/Archives/Public/www-style/2014Aug/0132.html
     - All the options were evaluated and the group originally
          leaned toward option D.
     - There was a lot of testing done to determine which behavior
          browsers currently use and there was no clear winner.
     - Eventually it was concluded that the optimal behavior was
          option G (Base values are interpolated values from
          all animations on this element and on all elements on
          which its computed values depend) with the beta variant(
          Base values are dynamic (i.e., if the expected value at a
          future time changes the running animation changes to
          match)).
  - RESOLVED: Use Option G Beta
  - RESOLVED: Animations and Transitions both really do have the
       behavior that non-interpolable properties switch at 50%
       of the timing function.
  - TabAtkins will write an e-mail summarizing the proposal phasing
       out current requirements for snapshotting some events.
  - RESOLVED: When animation-duration:0s, start/end events fire
              with 0 elapsedTime
  - RESOLVED: Iteration events only fire for iterations that are
       actually run e.g. those not 'absorbed' by a negative delay.
  - Pause events were discussed and had a lot of interest, but were
       deferred to level 2 in order not to delay Animations level 1.

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

Scribe: dauwhe

Animations
----------

  <sgalineau> http://lists.w3.org/Archives/Public/www-style/2014Aug/0132.html
  [Options from the e-mail:
  A: Base values are static values only.
  B: Base values are static values plus other values in same
       keyframe rule.
  C: Base values are static values plus other values in all keyframe
       rules in this @keyframes rule at same time.
  D: Base values are static values plus interpolated values from
       this @keyframes rule.
  E: Base values are static values at animation start time plus
       interpolated values from animations underneath this one (in
       cascading order) and this one, on the element to which this
       animation applies
  F: Base values are static values inherited from other elements at
       animation start time plus interpolated values from all
       animations, both under and over this one, on this element
  G: Base values are interpolated values from all animations on this
       element and on all elements on which its computed values
       depend]
  [E, F, and G also had related alpha and beta options, they are:
  alpha: Base values are static (i.e., chosen based on the
       animations known to apply at a certain future time when this
       animation is started)
  beta: Base values are dynamic (i.e., if the expected value at a
       future time changes the running animation changes to match)]

  sgalineau: Following up on telecon discussion -
  sgalineau: The basic story: we need to resolve how properties that
             depend on value of other property get resolved
  sgalineau: The height in ems depends on font size.
  sgalineau: There's an email from dbaon (link above) with possible
             scenarios.
  sgalineau: A. multiple animations depending on each other.
  sgalineau: At some point it gets really complex.
  sgalineau: I did some basic testing.
  sgalineau: You can depend on [A] across browsers,
  sgalineau: After that, there's no interoperability.
  sgalineau: [B] doesn't work.
  sgalineau: Two @keyframe rules with same selector, the last one
             wins.
  sgalineau: IE does [D] and [E], but it's not super smooth.
  sgalineau: A is all we have today.
  sgalineau: The same @keyframe rules should be like others in the
             system.
  sgalineau: I'm not finding evidence that people are bothered by
             the others not working.

  sgalineau: So, for level one we should resolve on a simple subset.
  sgalineau: A is the minimum we have today.
  sgalineau: B should work once people apply cascading across
             @keyframe rules.
  sgalineau: We can keep it simple.
  sgalineau: Some people do split animations across 2 or more
             @keyframe rules,
  sgalineau: But it's not common.

  astearns: One issue is dbaron just walked into the room so he
            missed the intro.
  * dbaron returns to the meeting room

  shans: looking at dbaron's post, C seems wrong.
  TabAtkins: That's a bad behavior.
  shans: Its bad to apply property changes in the future.
  shans: Seems strange to apply property values from the future in
         the present.
  sgalineau: Does it refer to 50%?
  TabAtkins: The keyframe updates the values that other keyframes
             will set.
  TabAtkins: If there was a 50% text size will resolve against ???
  <TabAtkins> If there was a 50% keyframe that set font-size, the
              "1em" in text-indent would resolve against that; since
              there isn't, it resolves against the base value.
  sgalineau: Only A works today across browsers.
  sgalineau: Thus it's hard to find people running into issues due
             to b, c, d not working.
  sgalineau: So to keep simple in level one, just use A
  sgalineau: So let's not go there today.

  dbaron: I think gecko does B since you cascade across keyframe
          rules.
  dbaron: I can't tell the difference between b and c in other
          browsers.
  sgalineau: Beyond that we can punt to future levels.

  shans: Did you test chrome?
  sgalineau: I did, it did A, If it did other stuff it was not very
             pretty.
  sgalineau: My tests were on font size.
  shans: I think we intended to implement D
  sgalineau: It may have but it's so not smooth you couldn't use it.

  sgalineau: If the animations property depends on other things,
             resolve that, but don't go further. Don't resolve
             across animations.
  sgalineau: Questions?

  TabAtkins: I think D is great idea.
  sgalineau: You have animations depend on each other.
  dbaron: In our code there's implicit dependence. Would need to
          store data explicitly to do D.
  TabAtkins: How do you do it?
  dbaron: We compute properties lazily in groups.
  dbaron: The cross-structure dependencies are implicit.
  TabAtkins: I'm not sure why this is...?
  dbaron: We need to build a list of what the properties depend on;
  dbaron: In order to make sure there are no cycles.

  sgalineau: I think D is interesting because people split animation
             into multiple keyframe rules.
  sgalineau: Styling in one, motion in another.
  sgalineau: It already has cross-dependencies.
  sgalineau: Finding problems around this is hard.
  sgalineau: If there are implementation concerns, it's really not a
             problem today.
  TabAtkins: Since people have hacked around the problem.

  dbaron: This tends to show up in properties people don't animate
          much.
  clilley: Is that cause or effect?
  dbaron: Lea ran into the problem with animating border-width.
  sgalineau: I haven't really seen more bugs than Lea's.
  dbaron: It's not massively hard, just have to build and maintain
          list of dependencies.
  shans: It would be hard to go back to A.
  shans: Because of how property resolution gets done.
  TabAtkins: We'd have to maintain un-animated properties separately.

  sgalineau: Okay, I hear were going towards D.
  sgalineau: Are we doing E too?
  dbaron: E would be harder for us.
  shans: Us too.
  shans: We don't order animations.

  plinss: is there an order that makes more sense for authors?
  dbaron: G beta, but it's really hard--do what I meant!
  TabAtkins: G beta is not realistic.
  TabAtkins: D is a reasonable compromise.
  sgalineau: D and E?
  TabAtkins: E is not the same thing. It requires remembering
             animation orders.
  TabAtkins: Rather just normal property orders.

  dbaron: This message might be confusing-
  dbaron: A list from A to G but also a list of the changes between
          items.
  dbaron: In D you're considering each animation separately,
  dbaron: In E you're considering all of them underneath it in the
          cascade.
  astearns: Does that change the results you're reporting about E?
  sgalineau: Yes, I don't think I was testing E properly.
  CLilley: What was that?
  sgalineau: astearns was asking if my misunderstanding of D vs E
             affected my results,
  sgalineau: I think so.

  sgalineau: Do we have agreement that D is what we want?
  TabAtkins: Right now, we think we do F in chrome.
  shans: But we might change our mind.
  TabAtkins: We don't do E, I'm sure of that,
  TabAtkins: E requires caring about ordering.
  TabAtkins: F applies everything together in the appropriate way.
  shans: You resolve style for element, then apply.

  dbaron: What's weird about E and higher is that you don't know...
  dbaron: E, F, and G all have alpha and beta options.
  shans: Can we come back after we test?
  dbaron: Part of what I dislike about them is that both alpha and
          beta are bad in confusing ways.
  dbaron: The difference between alpha and beta, with alpha you
          figure out the animation first, then run it.
  dbaron: With F alpha if you apply a 2nd animation to something
          that's already running, you need to include a future point
          of the animation.
  dbaron: If you're repeating it's not clear what to do.
  dbaron: Beta is doing it dynamically.
  dbaron: You might have a repeating value with 2 values oscillating,
  dbaron: And what you're getting might change as that value changes.

  krit: In SVG, you have to use dynamic...
  dbaron: Does the same thing happen in SVG if you're animating font
          size?
  dbaron: So SVG animations are doing beta.
  dbaron: I remember agreeing that something else was static, but
          not base values.
  krit: Keeping the base value is static is easier.
  krit: This was one of the huge issues with performance.
  dbaron: You're recomputing the whole thing every tick?
  krit: Yep.
  plinss: That seems more rational from the author perspective.
  plinss: If author sees their animation doesn't perform, they will
          change it.
  sgalineau: What's the value if it's not performance?
  krit: I'm okay with beta later, but not as the default.
  dbaron: Only with E, F, or G are you computing other animations
          with base value of other animations.
  shans: What's the expected value?

  TabAtkins: We're doing F alpha.
  TabAtkins: We do have them interact, but only based on the static
             value of the other animation.
  TabAtkins: Never mind
  TabAtkins: I think it's D.

  plinss: Authors want G beta.
  plinss: If that what they want to have,
  plinss: Are we blocking the future?
  sgalineau: If we agree on D, we can do more in future.
  sgalineau: How does doing D now and E/F/G later break all
             animations?
  TabAtkins: If you change from D to G beta you'll change the
             example.
  sgalineau: Shit.
  * sgalineau ^ technical term
  plinss: I'm loathe to prevent some hypothetical future version
          from doing this right.
  plinss: We always find a way to do it faster in future.
  krit: And SVG has been doing it for years.
  plinss: We've had no complaints about performance and we have
          interoperability.
  plinss: Should we leave this undefined for now?
  clilley: That's worse than anything else.
  clilley: Different implementations will do different things.
  clilley: One will do something different, that will become the new
           standard.
  shans: It's hard to tell what we're doing
  plinss: We should define this to break for now, explicitly have it
          not work. Dependent animation just won't work.
  dbaron: No. It's a breaking change.
  dbaron: Alpha and beta are only options for E, F, and G, we're
          implementing B.

  <TabAtkins> hober:
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3160
  <TabAtkins> hober:
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3161

  various: murmuring
  sgalineau: It's the same in Chrome and Firefox.
  TabAtkins: We're doing D and not anything higher than D.
  TabAtkins: They are interacting if you're going from 10 to 300 on
             width in Blink and Safari.
  TabAtkins: If they're not interacting, then it goes from 10 to 50.
  TabAtkins: If they are, then goes from 20 to 300.
  sgalineau: Yes.
  sgalineau: Looks fine in Firefox.
  TabAtkins: In some cases Firefox implicitly does D.
  TabAtkins: If you run 3161 in Firefox they do interact.
  dbaron: No, two properties in the same keyframe rule is the A vs B
          distinction.

  [Everyone is testing browsers]
  sgalineau: Do we want to send this back to list?
  TabAtkins: No. We'll figure this out.
  plinss: We're on a mission.

  <dbaron> http://dbaron.org/css/test/2014/
  sgalineau: We're back to A as the one you depend on.
  dbaron: They are a set of different behavior choices.
  dbaron: Both Chrome and Firefox are doing B,
  dbaron: You have to run the sequence.
  TabAtkins: We think we're in B only because of a bug. We should be
             in D.
  dbaron: This is computing base values.
  TabAtkins: We should be in F.
  shans: What's going on is we're pre-computing what the keyframes
         will be.
  dbaron: Everyone pre-computes what they are,
  dbaron: Not pre-computing would be beta option for E, F, and G.
  shans: Our engine is capable of not pre-computing, but we do the
         pre-computing to match previous behavior.

  TabAtkins: We recently rewrote all this code.
  TabAtkins: Let's change to not pre-computing, so then we'd be in F
             beta.
  krit: If you have transform with lots of values it would fall out
        of compositing mode all the time.
  TabAtkins: Possibly.

  dbaron: Do you know what IE does?
  gregwhitworth: We believe we do D
  * sgalineau got E wrong but believes IE did D
  dbaron: Will margin left work?
  gregwhitworth: Switching to margin since there's a bug on test
                 indent.
  dbaron: I expected to go from 0 to 10 or 30 then back to 0.
  hober: We're doing C or lower.
  gregwhitworth: We're D or higher.
  hober: What do expect for EF?
  dbaron: Don't load yet.

  CLilley: Test-based spec editing!
  [more testing in progress]

  dbaron: G is a weird case.
  dbaron: Gecko does B + G.
  dbaron: It does consider ancestors.
  TabAtkins: Our web animation code does F beta.
  TabAtkins: We bug-fixed our CSS code to get B.
  TabAtkins: If we remove that we'll get F beta.
  TabAtkins: Don't use EMS in your transform functions.
  krit: If you do beta and you won't have that problem.
  krit: You added a performance regression?
  shans: We added a correctness enhancement.
  shans: Long-term we want to support it.
  krit: It makes sense for uniting CSS animation with SVG animation.
  dbaron: We do use values from ancestors.
  andrey: prefix removed?

  hober: Our result for FG is 0 to 10 and back to 0
  dbaron: Gecko is going to 20 or 25 which is inexplicable.
  gregwhitworth: IE goes to 25
  krit: IE is doing F?
  dbaron: G
  krit: what about Firefox?
  dbaron: B
  krit: What did you intend?
  TabAtkins: The difference between F and G if they interact it's G,
  TabAtkins: So we're doing that.
  dbaron: We're doing B + G.
  shans: We're animating before computing.
  hober: I'm retrying F + G, we seem to go to 20-25.
  dbaron: Just like Firefox.

  dbaron: This makes animations more different from transitions.
  dbaron: You just animate from an old computed value to a new
          computed value.
  dbaron: We implemented animation as an extension of transitions.
  dbaron: If we do this the other way, it's more like you're
          recomputing the value rather than figuring out the
          animation.

  plinss: Are we closer to decision?
  dbaron: Which other stuff does this depend on?
  dbaron: Do you figure all this out at the start, or as the
          animation runs?
  shans: Does a keyframe rule specify a set of values that change
         over time?
  shans: or a ???

  plinss: Are we any closer to answer?
  shans: IE does G
  shans: Chrome core engine does G.
  florian: What if B + C test is the only wrong test? That's what
           presto does, and it overshoots a bit,
  dbaron: You're probably using a future keyframe.
  florian: It also overshoots D + E.
  gregwhitworth: B + C is not interoperable across browsers.
  gregwhitworth: IE and chrome keep font at initial size, Firefox
                 resizes.
  dbaron: Some tests depend on cascading keyframes
  hober: On b + c we go from 0 to 10,
  dbaron: It's not meaningful if you don't cascade keyframes.
  dbaron: What does webkit do on C + D?
  hober: From 0 to 10 and back
  dbaron: Webkit does b or c.

  dbaron: We're not adding new info from testing. Let's figure out
          what we want.
  florian: We've proved going to G is doable.
  dbaron: Is this g beta?
  Rossen: For us it's g beta.
  dbaron: Does it bounce to 30 pixels each time? You're doing
          EFG/alpha
  dbaron: If it bounces bigger each bounce, then it's beta.
  plinss: IE is G Beta.
  Bert: Does this defeat the purpose?
  dbaron: Presto is just doing the destination value.

  Bert: If everything is dynamic you can't pre-compute,
  Bert: Then you can't optimize.
  Bert: If a computer isn't fast enough, you may want to drop frames.
  Rossen: Or just use a stylesheet that doesn't do this.
  shans: This isn't the slow part
  Bert: Say you're scaling an image, you might want to pre-compute
        all images.
  Bert: Even the smallest computer can then keep up.
  TabAtkins: You probably don't ever want to do that; it would eat
             up a ton of memory storing the temporary images.
  TabAtkins: Our core implementation does G beta.

  plinss: I hear us gravitating towards G beta.
  plinss: It's consistent with SVG, we have implementation proof.
  plinss: Any objections?

  RESOLVED: Use G Beta.

  sgalineau: Values that don't interpolate.
  sgalineau: There was confusion- we wanted to make them switch at
             50% progress point.
  sgalineau: You'd switch from one to the other.
  sgalineau: I thought that would be true for transitions and
             animations,
  sgalineau: but dbaron said no.
  sgalineau: We still want to animate non-interpolated values at
             50%, and only for animations, not transitions.

  TabAtkins: We don't want different behavior for animations and
             transitions.
  TabAtkins: It's okay to have initial value of transition to only
             those that can be smartly interpolated.
  dbaron: It can be a different in when you start CSS transitions.

  dbaron: The other issue is that I'm still worried about shorthands
          in the transition property value.
  dbaron: transition: font
  dbaron: Today that means you're transitioning font size and weight
          and nothing else.
  dbaron: Maybe this isn't too important,
  dbaron: It's a bigger deal for border.
  TabAtkins: Border will work better.
  dbaron: I'm worried about this change for compatibility.
  dbaron: Nobody has edited or implemented this.
  sgalineau: I was waiting.
  krit: Is there a problem if there's a difference between CSS and
        SVG?
  shans: Do you copy into animation before sending it down? I don't
         think it's an issue.
  shans: You should do what seems most useful.

  dbaron: The original transition spec had funny rule for visibility.
  dbaron: There are similar things with display or other things.
  dbaron: I can see it being useful but worried about the
          compatibility risk.
  TabAtkins: You're not worried about shorthand compatibility risk?
  dbaron: I'm worried about it all.
  TabAtkins: We can fix initial value problem,
  TabAtkins: Or changing all to mean not all of them.
  <sgalineau> Today 'all' really means all properties for those
              values that interpolate so we could also just keep it
              that way.
  krit: If you want to switch key values between key frames is that
        possible?
  dbaron: Is it possible with animations?
  dbaron: Is this animations only or animations and transitions?

  <gregwhitworth>
http://lists.w3.org/Archives/Public/www-style/2011Apr/0079.html
  dbaron: This is more like the previous issue.
  dbaron: I didn't think that's (the link) the issue we are
          discussing.
  TabAtkins: We were discussing the general issue because it hasn't
             shown up in spec.
  dbaron: This is a different issue.
  <sgalineau> The issue gregwhitworth linked to is next for
              discussion.

  krit: So webkit switches immediately.
  krit: No transition is applied.
  sgalineau: There's another thing: when you do switch, whether
             duration gets involved.
  krit: It's better not to define the ideal, but to be interoperable.
  krit: Mostly.
  dbaron: I think the plan is that duration would be involved.
  dbaron: It would switch when the timing function crossed 50%.
  krit: This is not what SVG animations do.
  krit: SVG switches at 50% of the time rather than 50% of timing
        function.

  TabAtkins: We did discuss making non-interpolatable work only if
             the timing function was in steps.
  TabAtkins: In most animations they would not animate.
  dbaron: And there would have to be only one step.
  TabAtkins: There will be a step mid-function in level 2.
  CLilley: People didn't want it, something had to be defined to
           happen.
  krit: What do we gain from that? We can still do that with
        animation triggered by a transition.
  dbaron: The gain is with display.
  TabAtkins: Or border style.
  TabAtkins: Display is a big one.
  krit: It wasn't really used in SVG a lot, don't expect it to be
        used in CSS much.
  dbaron: I've seen people want it for display.
  TabAtkins: People want to do visibility, we've special-cased it.

  dbaron: I don't have strong opinion.
  dbaron: Except when whoever implements first should know we might
          have to change.
  dbaron: I guess I'm okay changing the resolution to be for
          transitions.
  TabAtkins: It might be backing down to just steps.
  dbaron: Or to just for transitions.
  sgalineau: We have resolution for css transitions.
  RESOLVED: Animations and Transitions both really do have the
            behavior that non-interpolable properties switch at 50%
            of the timing function.

  <sgalineau> http://lists.w3.org/Archives/Public/www-style/2011Apr/0079.html
  sgalineau: In the initial animation spec it requires snapshotting.
  sgalineau: Changes to your keyframe rules have no effect, it
             doesn't care what's going on.
  sgalineau: An issue that was raised is that's not something we
             want to do.
  sgalineau: We would allow animation property to change dynamically.
  sgalineau: We never concluded on what that means and how it works.
  <sgalineau> in particular
http://lists.w3.org/Archives/Public/www-style/2011Apr/0352.html
  TabAtkins: The start time stays constant but everything else is
             adjustable.
  sgalineau: We don't want to double-fire start events,
  sgalineau: Or is that just a consistency issue?
  Bert: You can change the past?

  dbaron: What is the particular issue?
  sgalineau: The spec requires snapshotting,
  sgalineau: We don't want that.
  dbaron: I though we had a resolution on what replaced it.
  sgalineau: It's possible.
  TabAtkins: We appear to snapshot now.
  dbaron: Let me look at the minutes...
  <dbaron> http://lists.w3.org/Archives/Public/www-style/2012Nov/0261.html
  dbaron: That one does say details TBD.
  sgalineau: The issue is resolving the TBD.

  sgalineau: You mentioned that gecko the model accepts changes
             other than animation delay.
  dbaron: The model is that we compute a start time and then let you
          change everything else.
  dbaron: We may honor a dynamic change to animation delay.
  TabAtkins: Before the delay, it's the moment the animation starts
             applying, which is not controllable.
  dbaron: Yes.
  TabAtkins: When I hover over the test case, no longer speeds up in
             chrome.
  dbaron: It still speeds up in safari?
  hober: Yes.
  <hober> Rossen:
http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3163
  dbaron: There is now a list of resolutions to editors in the spec.
  sgalineau: Most of them are in.

  dbaron: What are the questions about what we should have?
  TabAtkins: What is adjustable?
  TabAtkins: Do you fire a 2nd start event?
  TabAtkins: What about at the end?
  sgalineau: You can change keyframes that haven't run.
  dbaron: I think the hard part is events stuff.
  dbaron: You compute things as if animation started when it
          started, and always have those values.
  TabAtkins: I agree, events is the hard part.
  dbaron: I expect Brian Birtles would have strong opinions about
          when events should fire.
  TabAtkins: Should we declare everything is touchable and ask Brian
             about event firing?
  dbaron: There may be some value in not re-firing at start and end.
  TabAtkins: What if you're past the end? Do you fire the end?
  TabAtkins: If you adjust the delay to a large negative value, do
             you fire the end event even though it didn't end, but
             changed from running to not running?
  dbaron: Brian recently rewrote this code 'cause he thought it was
          wrong.

  Bert: Even without dynamic, what if there's a huge negative delay?
  TabAtkins: That's defined.
  Bert: Does it have a start?
  TabAtkins: Yes. It started before you started...
  <sgalineau> So if you change animation-delay after the animation
              started running, making the delay larger has no effect.
              But if we make the delay negative, can we fast-forward
              or is it also ignored?
  CLilley: If you go into a video after an hour, and you missed lots
           of events...
  dbaron: There are lots of fun questions. Duration zero and
          iteration...
  TabAtkins: We decided not to fire an infinite number of animation
             events.
  dbaron: I'd say you only start once and only end once.
  TabAtkins: By iteration boundary, just fire an event whenever you
             pass through.
  TabAtkins: You usually don't care which iteration.
  TabAtkins: So you're not worried about duplication, missing ones,
             etc.
  dbaron: And we shouldn't try to file a pile of iteration events or
          skip iteration events because of duration/etc. changes.

  sgalineau: We didn't resolve animation delay issue, if you make it
             bigger is there no effect,
  sgalineau: Or do you fast-forward?
  TabAtkins: The delay should get adjusted.
  TabAtkins: The delay is just a component of its progress, no
             reason to special case.

  dbaron: Should someone write up for www-style?
  TabAtkins: I can do it.
  ACTION: TabAtkins to write up proposal for www-style
  <trackbot> Created ACTION-636

  <sgalineau> http://lists.w3.org/Archives/Public/www-style/2014Sep/0056.html
  sgalineau: Let's talk about Brian's email.
  sgalineau: He had three options
  sgalineau: What happens visibly?
  sgalineau: And what in terms of events?
  dbaron: I think TabAtkins and I had the same preference on this.
  TabAtkins: A
  TabAtkins: B has its arguments. A is better on limiting behavior.
  TabAtkins: I don't know what we implement.
  sgalineau: Regardless of ???
  dbaron: If you iteration count infinite and duration zero, you
          should act as if iteration count zero
  TabAtkins: Or in any finite value.
  TabAtkins: One disadvantage is showing rounding behavior.
  dbaron: That doesn't involve any iteration events.
  sgalineau: So it's like a zero-second animation with finite
             iteration count.
  RESOLVED: When animation-duration:0s, start/end events fire with 0
            elapsedTime

  <sgalineau> http://lists.w3.org/Archives/Public/www-style/2014Aug/0393.html
  sgalineau: Interaction of negative delay, browsers do the right
             thing.
  sgalineau: Another question is what happens to events.
  sgalineau: I can't remember what Brian proposed.
  sgalineau: If you have a delay that is the negative of your
             duration, that one should not fire events.
  sgalineau: Otherwise, I think if your negative animation delay is
             larger than one iteration, you just swallow the
             iteration.

  TabAtkins: Both resolutions sound reasonable.
  sgalineau: #1, no start and end events are fired.
  sgalineau: If you have more than one iteration, and delay is
             larger than iteration, then don't fire any events.
  sgalineau: In the +5 -5 case, he says events should not fire.
  TabAtkins: He's just looking for consistency.
  TabAtkins: But if you don't fire events for things that start and
             end in the past, then you not fire in that case.
  TabAtkins: Which would be consistent with how we handle changing a
             delay in the middle of an animation.
  <dbaron> http://lists.w3.org/Archives/Public/www-style/2014Sep/thread.html#msg55
  sgalineau: Start and end will fire, but no iteration events fire,
             and no iterations occurs.
  TabAtkins: Iteration events fire whenever you play through an
             iteration boundary.
  TabAtkins: But start and end always fire.
  sgalineau: That makes sense.
  TabAtkins: That's consistent with the infinite case, too.

  RESOLVED: Iteration events only fire for iterations that are
            actually run e.g. those not 'absorbed' by a negative
            delay

  Bert: In example B, the values are simplified,
  Bert: Just like 360 degrees simplify to 0.
  TabAtkins: What email are looking at?
  Bert: 393
  dbaron: Must be from August.
  TabAtkins: It's not really simplifying, it's in the past so we're
             not firing events.
  Bert: The effect is the same.
  TabAtkins: Your explanation doesn't extend to other situations.
  Bert: How can I explain this to the user?
  TabAtkins: The animation never experienced the first iteration.

  sgalineau: If your animation is applied in a paused state, does
             the start event fire when paused?
  TabAtkins: I don't know.
  shans: I think we disagree, I think it should fire right away,
         Sylavin thinks it should fire when unpaused
  TabAtkins: We are clearly inside the animations progress, so it
             should fire.
  plinss: Any time we fire a start, we should fire an end.
  sgalineau: The confusion is that all start tells you is that it
             applied, not that it's running.
  TabAtkins: You can't tell about pauses from start events.
  shans: Pause events are a good idea.
  TabAtkins: If you're trying to manually sync with animation, then
             you need to know.
  TabAtkins: You'd have a start event then pause.
  plinss: You can't pause before you start.
  TabAtkins: Assuming pause events give you time, it should be zero
             in case it's paused at start.
  sgalineau: Should we add pause event to level one?
  TabAtkins: I don't have an opinion.
  plinss: I don't want to delay REC.
  TabAtkins: We could add it quickly.
  shans: We can delay.
  TabAtkins: I'm okay with that
  <glazou> <adjourn>

  fantasai: Does anyone have objection to display module using new
            process?
  dbaron: Let's save that for tomorrow, so we can resolve to move
          everything to move process.
  fantasai: Just want to make sure nobody objects, since it's
            already in the pipeline to be published on Thursday.
Received on Wednesday, 15 October 2014 18:10:50 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:25 UTC