- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 13 Nov 2012 22:52:45 -0800
- To: "www-style@w3.org" <www-style@w3.org>
Animations
----------
- Discussed snapshotting vs. dynamic modification of animation parameters.
- RESOLVED: Change the animation properties to be dynamically changeable,
details TBD.
- RESOLVED: @keyframes can be dynamically changed
- RESOLVED: Copy over the pseudo-element info from transition events to
animation events.
- RESOLVED: animation-name's length is authoritative. Other animations
properties are adjusted to its length.
- RESOLVED: When you encounter duplicate animations names, last one wins.
- RESOLVED: Make *animations* transition *all* properties. Unless otherwise
specified, discrete properties take their starting values below
50% timing function progress, and end values above 50% timing
function progress.
Transforms
----------
- RESOLVED: Accept Aryeh's proposal regarding transform parents,
exact wording TBD.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16328#c4
- Bug 15605 (w-parameter for perspective) needs review from implementers:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15605
- Discussed 2D interpolation methods for transitioning transforms.
====== Full minutes below ======
CSS Animations
--------------
sylvaing: What do we do for TTA? Something every week?
plinss: If there are issues, our policy is to bring them up. We just
confirmed through prioritization that TTA is our top priorities,
so they'll get interrupt priority.
<sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=14713
sylvaing: This is about dynamic changes to animation properties or
keyframes.
sylvaing: Spec since the beginning requires animation property or
keyframes to be snapshotted at the start of the animation.
sylvaing: David and Simon agree that it should be more open to dynamic
changes while it's running, such as changing the duration.
sylvaing: We haven't defined in detail how that works.
dbaron: I believe FF's model is that, at the first moment in which the
animation-name appears in the animation list, we determine the
start-time for the animation.
dbaron: This is the start time at the end of the delay (I think).
dbaron: As long as that animation name stays in the list of animations,
that's the start time we use for the animation.
dbaron: And we continue using that start time for all other things.
dbaron: I think basically anything else can change.
dbaron: So I *think* if you change the delay it has no effect, because
we compute the "start" time as the end of the delay.
dbaron: But I'd have to confirm.
dbaron: Effectively, you just recompute all the parameters of the
animation at every moment based on the current values.
<ChrisL> all the parameters are recomputed at each tick in the animation
dbaron: Exception is pausing. When running->paused, record the time
you paused. Switch from paused->running, adjust the start time
forward by the amount of time it was paused.
plinss: if you change things while paused, it can put you in a different
position?
dbaron: Yes. Change the animation-duration while it's paused, and it'll
live-move you to the new position.
dino: I don't like starting it at the end of the delay.
dbaron: I agree - I probably should have made it record from the start
of the delay instead, so it can take delay changes into account.
dino: We snapshot right now, but the underlying engine supports modification.
dino: We have all the infrastructure so we can expose it to JS.
sylvaing: I'm okay with making the animation properties dynamic.
sylvaing: We need some prose in the spec to be more explicit.
sylvaing: For example, "animation-name: b, c, d;
animation-duration: 2s, 3s, 4s;",
then I change to "animation-name: a, b, c, d;",
does it restart b, c, d, or does it consider them as having
never left the animation list?
dbaron: b,c,d never left the list.
sylvaing: Okay, we need that written down.
dbaron: I wonder what Brian Birtle thinks about this, given his work.
TabAtkins: Based on me working with him, I think this is in line with
what he wants.
dino: Further wrinkles. What happens if your animation is almost done,
you shrink its duration so it's already over? Do you get an end
event?
TabAtkins: I think *not* delivering one would result in bad accidental bugs.
dino: Okay, further answer. Animations with many iterations. Just
before the first iteration ends, you shrink the duration so that
the entire animation is over. Do you get tons of iteration
events, one after the other?
TabAtkins: I can be argued either way on whether to deliver iteration
events that didn't "actually" pass. I think it might be
acceptable to have those inconsistent.
dino: Okay. So there are multiple things like this that need to be
resolved and specified.
sylvaing: Right - right now everything is simple, because they can't
change.
dino: We'll have to check every state transition - an animation that
is done but filling (still technically running), but then has
its duration changed so that it should still be running?
dino: Need to work out the full state machine for all of this.
plinss: (re: iteration events) maybe only deliver the last iteration,
updating you to the current state.
ChrisL: Scrubbing was one of the things that SMIL got wrong - time
resolution was permanent, so if you scrubbed and then ran it,
it would jump back to the time it had gotten itself to.
dbaron: [draws a table of states on the whiteboard]
<dbaron> columns: before / 1st iter / 2nd iter / 3rd iter / after
<dbaron> rows: running / paused,
happens immediately / paused,
happens when unpaused
dbaron: If we define what fires for every transition between these
cells, is that sufficient?
dino: Yes.
dino: (But there may be another column or two on that graph.)
sylvaing: Okay, so I think there's agreement to make these properties
dynamic.
<dbaron> And I think there's agreement that the recorded start is the
start before the delay
RESOLVED: Change the animation properties to be dynamically changeable,
details TBD.
ACTION sylvain to define what happens when animation properties are
changed dynamically.
sylvaing: So, keyframes.
sylvaing: Changing those on the fly while animation is running.
sylvaing: The concept makes sense when the animation iterates - when
the next interval takes the changes into account.
sylvaing: If you have an animation that runs once, I dunno.
dino: It sounds testable, sure, but internally it's actually kinda
difficult - animation may be running on another thread, and
there's a disconnect in processing times.
TabAtkins: Conceptually, I don't see anything wrong with changing them
mid-animation.
glazou: I have a use-case. A long-running webapp animation may have a
large duration. If you change it, you don't want to wait for
an entire iteration to go by.
sylvaing: Are there any animation functions in @keyframes?
TabAtkins: Only the timing function.
glazou: I think that dynamic changes of animations will actually be a
reasonably common case (editing is hard right now, but CSSOM
will improve)
sylvaing: So what about changes of keyframes during an iteration event,
intending for the next iteration to use new values?
TabAtkins: There may by a delay if you need to deliver the changes to a
separate animation thread, but otherwise it should work fine.
TabAtkins: I think we're doing work on our end that should make it
automatically do a smooth transition over to the new values
when it discovers that it's overshot and needs to change tracks.
dino: But then we need to specify that.
TabAtkins: We'll have non-interop a bit anyway, because of timing issues
based on whether you do animation on a separate thread or not.
I think we can leave it alone and spec after things have shaken
out.
RESOLVED: @keyframes can be dynamically changed
<glazou> yay
<sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15846
sylvaing: Next. Transition events report what pseudo-element of the
element the transition is running against.
sylvaing: We don't have it for animation events at the moment.
dbaron: We should just copy it.
RESOLVED: Copy over the pseudo-element info from transition events to
animation events.
* ChrisL imagines animating font-size on :first-line
* SimonSapin is glad not to implement that
<sylvaing> http://lists.w3.org/Archives/Public/www-style/2011Nov/0020.html
sylvaing: What happens when you have duplicate animation names in the
animation-name property.
sylvaing: Seems that last one wins.
dbaron: I think we resolved that and I edited it already.
dbaron: A similar thing is which animation property's length is the
winner. I propose that animation-name define the number of
animations, and every other property gets padded/clipped to
that length.
dbaron: This matches what backgrounds/etc do.
dbaron: I may have already edited this into the draft.
RESOLVED: animation-name's length is authoritative. Other animations
properties are adjusted to its length.
ACTION Sylvain to make sure that animation-name's length is definitive,
and edit it to be so otherwise.
RESOLVED: When you encounter duplicate animations names, last one wins.
<oyvind> that last resolution seems unclear
<glazou> oyvind: explain ?
<oyvind> current draft says that the last wins *at any particular point
in time, for a particular property*
<dbaron> http://dev.w3.org/csswg/css3-animations/#list-matching already
has the first of those two resolutions edited in, actually
<TabAtkins> oyvind, when assembling the set of property values that
define the animation, the index of the last occurrence of
the animation name is what is used.
<dbaron> oyvind, oh, it's about what happens if the same animation-name
is specified twice in the list
<dbaron> oyvind, which duration, delay, timing-function, etc., does it use
<glazou> oyvind: 'animation-name: foo foo"
<dbaron> oyvind, the answer is that it's the last occurrence of that
animation-name in the list
<oyvind> dbaron, ok, I misunderstood somewhat
<sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=14599
<sylvaing> http://jsfiddle.net/leaverou/jwHva/2/
sylvaing: In this example, if you remove border-style:solid, the animation
stops working.
<sylvaing> http://lists.w3.org/Archives/Public/www-style/2011Oct/0834.html
dbaron: I think I wrote a response for why this is crazy.
TabAtkins: The reason why it's problematic is that border-style is not
animatable. Thus, since the default (pre-animation) value
of border-style is none, the animation doesn't change it to
solid. And, since it's "none", the border-width computes to
zero, and so no animation happens at all.
leaverou: Authors find this super-confusing in my experience.
dbaron: There's an even more subtle issue here.
dbaron: Related to the processing model.
dbaron: When animating from A to B, there's an idea that it overrides
some of the properties, and only those.
dbaron: So this animation actually overrides 13 properties. border-image,
border-top-style, border-top-color, etc.
dbaron: For each keyframe, you get a computed value from it, and then
you animate the computed values between.
dbaron: However, in some cases, for border-width, the computed value
depends on border-style.
dbaron: Which value are you using? The base value, or the value that
the keyframe is overriding?
dbaron: And this gets more confusing.
dbaron: Say you have a 50% keyframe here with only a "border-width: 10px;"
property.
dbaron: What border-style is this resolved against?
dbaron: Gecko currently resolves it against the base value.
dbaron: (It also does this for the other keyframes.)
dbaron: The spec's processing model just doesn't really care about the
fact that computed values can depend on other computed values.
dbaron: I think it should, but I doubt any browser really does it.
dbaron: I think a testcase that covers only the issue I was talking about
would be one that animates font-size and some length in ems.
ChrisL: In SMIL anything can be animated. It just switches halfway through.
dbaron: halfway through the timing function (which makes step-start and
step-end magically work)
TabAtkins: Worst case, can we separate this out, so that non-animatable
properties with constant value are still paid attention to
and "animate".
ChrisL: That sounds like doing 3/4 of the work and just stopping.
glazou: We could also just say non-animatable properties freeze at their
first keyframe value.
dbaron: Regarding font-size and length in ems, make sure you test both
when the two properties are in the same keyframe, and when they're
not.
<dbaron> ... and in different @keyframes on different elements.
TabAtkins: So 3 cases of increasing complexity.
<sylvaing> cool border transitions:
http://thecodeplayer.com/walkthrough/simple-yet-amazing-css3-border-transition-effects
glazou: So what about my "freeze at frame 0" idea?
dbaron: I think that has a higher chance of web compat problems.
dbaron: The problem with all of these is potential web compat.
glazou: Can we seriously not do better than just making this work?
<ChrisL> I'm arguing for fixing it now by defining animation of
enumerated values
ChrisL: Are you saying that people are relying on the behavior in that fiddle?
dbaron: I don't know.
dbaron: Webdevs often try things, find they don't work, and then don't
remove them.
ChrisL: So if we fix it, something might suddenly start working and
break a page.
dbaron: I suspect we could get away with making this change in animations.
dbaron: I suspect not in transitions, because it defaults to "all".
dbaron: I suspect that if we fix it, we're adding a minimum of 4 months
to the spec.
ChrisL: Yes, but that avoids 3+ years of us explaining why it's stupid.
dino: I don't think many authors have hit this particular case. Or they
do and they screw around until it works.
leaverou: I think this change's impact will be smaller than gradient
angles flipping. ^_^
dino: I'd like to get some compat data on this first.
TabAtkins: Can we put a time limit on this?
dbaron: Do you know why Gecko doesn't allow you to style the color of
the radio button dot?
dbaron: Because hotmail.com styled all their radio buttons with
"background-color: green; color: green;", presumably on the
theory that only *one* of them would work.
TabAtkins: Okay, so suggestion is this: Allow all properties (except
maybe animation properties) to be animatable. Discrete
properties swap their values halfway through the timing
function (to match SMIL).
<dbaron> (doesn't apply to transitions)
dino: I don't object to putting this in the spec, but would then like
time to investigate compat.
* Bert thinks that leaves a small pb to decide at 50%:
0% {border: 10px solid}
50% {border-width: 5px}
100% {border: 0px none}
is the border already none at 50% or only at 50.00001% ?
<dbaron> depending on whether timing function output is greater or
less than 0.5
leaverou: If you have cubic-bezier with out-of-range params, you can
have it hit 50% multiple times. What happens there?
<dbaron> so it might swap more than once
<dbaron> (though we don't think so)
dbaron: It takes the first/last value depending on whether progress
is currently above/below 50%, so it'll flip multiple times.
<leaverou> example of timing function that reaches 50% multiple times:
http://cubic-bezier.com/#0,1.8,1,-0.79
RESOLVED: Make *animations* transition *all* properties. Unless otherwise
specified, properties take their starting values below 50%
timing function progress, and end values above 50% timing
function progress.
<dbaron> cubic-bezier(0.25, 3, 0.75, -2)
<dbaron> (you can cross 50% more than once)
<Zakim> Bert, you wanted to ask if we can now remove the Animatable
line from table.propdef.
dbaron: No, really it's about how to interpolate the property.
<dbaron> we could maybe rename Animatable: to Interpolation:
dbaron: Do we at least have an issue filed on the processing model
stuff we're discussing?
dbaron: How you compute the base values for the properties that we were
discussing a moment ago?
ACTION tab to test the processing model of animations where computed
values of animated properties depend on each other.
Transforms
----------
Scribe: fantasai
<krit>
https://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&product=CSS&component=Transforms&resolution=---&list_id=1271
<smfr> http://jsfiddle.net/fNxAQ/1/
<smfr> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16328
smfr: We think that the only real substantive issue in the transforms
spec is this bug
smfr: which talks about the containing block terminology used in 3D
transforms rendering part of the spec
<smfr> http://jsfiddle.net/fNxAQ/3/
smfr: and to illustrate that, jsfiddle that Ted just linked to,
hopefully someone can project
smfr: The issue here is related to 3D rendering contexts and
smfr: how 3D transforms propagate across containing blocks,
smfr: Is that jsfiddle on the screen?
[yes]
[fiddling with example]
smfr: 2 containers here,
smfr: border box with perspective
smfr: Top intermediate div with no style
smfr: ... with rotate-y
smfr: issue here is whether perspective on grandparent affects rendering
of that transform
smfr: i.e. whether the intermediate box flattens it
smfr: i.e. whether the intermediate and the box are members of the
same 3D context
smfr: I believe in FF, intermediate box causes flattening to occur,
b/c it's the containing block of the blue box
smfr: in Webkit it doesn't
smfr: FF more close to wording in current spec
smfr: Transforms looks at containing block hierarchy
smfr: in bottom example, container, then inside an image, and image
has a block sibling
smfr: image gets an anonymous block container
smfr: in this case the containing block for the image is anonymous
smfr: question here is whether that anon box prevents transform
smfr: [... gecko]
<krit> http://jsfiddle.net/fNxAQ/6/
dbaron: Gecko doesn't actually create an anonymous box here
[fantasai explains what gecko does for mixed block-and-inline content,
and why it doesn't make that box]
smfr: implementation doesn't matter much; but if you adhere to strict
wording of spec, there's an anon box that's your containing block
smfr: Webkit's implementation is falling out of some other things going on
smfr: Detail is something like we're looking at ancestors that are
transformed or that are positioned or that have other properties
that create stacking contexts
smfr: So it's not conforming to the spec, and not always predictable
dbaron: You say you're looking for ancestors starting ...
dbaron: starting from thing that has a 3D transform?
smfr: Any of those things between that and the transform will cause
flattening to occur
smfr: so webkit won't flatten otherwise
<smfr> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16328#c4
smfr: wording in spec is very tight, maybe need something in between
smfr: Aryeh suggests defining a new type of container called transform
parent, and then make a list of things that make something a
transform parent
smfr: [quotes]
smfr: [...]
smfr: Aryeh's suggestion.. A is closer to what authors expect, and
B doesn't have anon containing block problem
<dbaron> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16328#c0
<dbaron> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16328#c4
smfr: Just got browser shots from IE10
smfr: Which is similar to FF behavior
smfr: Opera shot didn't show any support for 3D transforms
smfr: Question here is whether we try to cook up some wording similar
to Aryeh's suggestion
smfr: or what
smfr: input from other implementers?
[...]
sylvaing: Our rendering in this case is may not be really related
krit: Do we want to follow Webkit, or different approach?
fantasai: Seems to me that webkit's behavior is closer to what authors
want; wouldn't want everything to flatten all the time, right?
dbaron: Authoring perspective, want it never to flatten, but problem
is it's too expensive?
smfr: Want it to flatten in certain cases
dbaron: You'd want the default to be the other way around?
smfr: when we were designing this transform property, did think it
would be good to not flatten always, but didn't do that b/c
thought it would be fairly significant change to CSS
smfr: Web pages are typically flat, and having them not-flat would be
strange
smfr: That's why default style is to be flat
smfr: Time authors use preserve3D is when they build up 3D hierarchies
of objects they want to sit in the same perspective
smfr: It's fairly unusual for someone to put perspective on document
and expect the whole thing to be 3D
smfr: Generally have islands of 3D
smfr: So we expect authors to sprinkle around preserve3D between things
with perspective and objects they want to show in 3D
smfr: not too bad, usually only 1-3 levels of elements in between
dbaron: Substantive implementation differences. If we pick a different
rule, would it be more burdensome?
smfr: I think a rule like Aryeh's it'd be a little work for us, but
not too bad. Have to flatten a little more than we're doing
smfr: The obvious flaw with using containing block is in the case where
you have an anon containing block, there's no way author can
style that to make it preserve3D
dbaron: Other reason bz pointed out is that containing block is not an
element, it's a rectangle
smfr: didn't Anton fix some things wrt that?
antonp: yep, but nothing published yet
antonp: but could work around that, if that's what you want
smfr: If no one has any more input, then action is on me to write up
wording for spec ~ Aryeh's comment #4
<dbaron> sounds good to me
krit: Can we resolve on some kind of wording ?
plinss: Do we have wording?
dbaron: Simon was proposing to take an action to propose wording
ACTION smfr: propose wording for 3D perpsective containing block thing
RESOLVED: Accept Aryeh's proposal, exact wording TBD
<krit>
https://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&product=CSS&component=Transforms&resolution=---&list_id=1271
krit: Some other items on issues list
krit: Did some wording on it, but needs review from implementers
krit: Not necessarily an issue, but should be reviewed
ACTION sylvain: look into bug 15605
dbaron: I trust Aryeh on this
dean: We're happy with this
<krit> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17017
krit: Next issue is concern of dbaron's
krit: we have some interpolation code, how you can interpolate between
3D matrices
krit: But don't say how to interpolate between 2D and 2D matrices
krit: So, I looked a bit at source code from FF and Webkit
krit: FF has ... like 2D interpolation, modified to work on 2D
krit: Webkit operates on 3D all the time
krit: We have 4x4 matrix
krit: we transform everything to 3D first, then take 2D values from
the resulting matrix
dbaron: I had testcases; possible it's been fixed but;
dbaorn: If you do 2D transform in webkit between certain positions,
it'll do something like this [handwave] and then snap to that
position
<ChrisL> do you assume the three unused values are 0 0 1?
<ChrisL> because they might not be if you had scaling in there,
dbaron: If you transition between matrices where sign of determinant
is different
dbaron: The matrix algorithm will produce interpolation that will spin
you around x or y axis, and webkit will then throw out the 3D
part of that
<dbaron> http://dbaron.org/css/test/2010/transition-negative-determinant
dbaron: Chrome seems to get these right now, but it didn't used to
<smfr> chrome and safari do different things with the bottom row
dbaron: That said, bottom row is looking like it's doing something 3D
to me
dbaron: so I think Chromium is interpolating the bottom in 3D
dbaron: Firefox is interpolating in 2D
<smfr> in safari, middle row 2nd from right is weird
[random discussion of these cases and what's happening in various
browsers/versions]
ChrisL: Promoting to 3D and then interpolating doesn't necessarily
give you the wrong answer, just depends how you do it
krit: Do we want to define an algorithm for this?
krit: It seems to be hard in webkit atm
dbaron: Seems we should say what happens, how you interpolate between
these things
krit: Are implementations willing to change?
dean: FF must have extra code to handle this
dbaron: We have separate paths for 2D vs 3D
dean: What's 3D vs 2D?
dbaron: The test for 2D is based on the components of the matrix
dbaron: one other reason we want this code is... I don't think we support
3D transforms in all cases... though maybe we do
[...]
dean: It could be that the 3D interpolation is ok for enough cases
dean: and we're just seeing some bugs in webkit's implementation
dean: would still like to know why chose to customize algorithm for 2D
dbaron: he's in New Zealand...
dean: I don't trust anyone from New Zealand
dean: I accept the resolution.
krit: Even if we have interpolation in 3D space, still need to specify
how get 2D components for e.g. getComputedStyle
krit: It's the main thing left
krit: I'd like to have just one algorithm in the spec, not multiple
algorithms. 3D is already complex enough
plinss: Anyone take an action to do research and get back?
krit: What do you expect as the result?
dbaron: Are we interoperable on 3D interpolation, in general?
<smfr> sounds like we need some test cases!
krit: Webkit is mostly following the algorithm in the spec
dean: Made an effort to match the algorithm from you, although we may
have bugs
[more discussion of browser versions]
krit: They look different. That might be a bug
dbaron: Looking at our code, looks like we're still doing quaternian
thing for both 2D and 3D, just do a different decomposition
dean: Is the decomposition for speed or aesthetics?
dbaron: Think it's for aesthetics
dbaron: we use a decomposition that never generates a perspective
dbaron: sometimes the 3D comp will generate a negative 1 perspective
instead of 1
dbaron: that's what leads to weird zoom-in-zoom-out behavior
ChrisL: That's not perspective, that's scale, right?
dbaron: Or maybe it's [this other] component that's affected
ChrisL: Looks like it's the scale factor
dean: I think if you get anything other than 1 in 4,4, you're done
dbaron: It's something where you can take a 2D matrix, run 3D decomp,
and get a -1 instead of a 1 in some parts
krit: Webkit always assumes 3D, even if given 2D
krit: You could use algorithm from 3D transforms and do some weird
stuff like setting 1 for perspective
krit: at the moment it's undefined
Options are
1. Define 2D decompositing algorithm
2. Leave it undefined
3. Use 3D decomposing algorithm everywhere
krit: Could also defer this issue to next level
dean: Dunno. It is an interop issue.
dean: If you query getComputedStyle halfway through a transition, would
get different values on different browsers
dbaron: Other thing is that algorithm could be tweaked so that the 3D
algorithm will always work
dbaron: I'd like to at least email Matt Woodrow and Tim and ask them
why we're doing what we're doing
ACTION dbaron: investigate motivations for gecko approach to 2D matrix
interpolation
11:58 * RRSAgent records action 4
Meeting closed.
<TabAtkins> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1871
<TabAtkins> dbaron ^^^
Received on Wednesday, 14 November 2012 06:53:40 UTC