- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 15 Oct 2014 14:10:22 -0400
- 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