- 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