- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 14 Feb 2013 20:15:05 -0800
- 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 ======
Transitions
-----------
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):
http://logs.csswg.org/irc.w3.org/css/?date=2012-08-15
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
results
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
animations
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
animation
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
animation
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
property
<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
stops?
smfr: Think dean, me, dbaron, anyone else might meet to go through use
cases
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
state
<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
case?
...
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
1
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