- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 20 Mar 2015 02:41:57 -0400
- To: www-style@w3.org
Transitions ----------- - RESOLVED: No special treatment of 'z-index: auto'; it's not possible to transition between auto and other z-indices. https://www.w3.org/Bugs/Public/show_bug.cgi?id=16265 - RESOLVED: CSS transitions can go to CR. CSS Transforms -------------- - RESOLVED: Include Takagi-san's definition of linear scale in CSS transforms (details available here: https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Specifying_decomposition_of_scale). - RESOLVED: Publish new WD of CSS transforms with Takagi-san's changes. - RESOLVED: We will add translate, rotate and scale properties in CSS transforms level 2 - Discussed ways of preserving the animation end state after an animation finishes and whether/how to reflect this in the DOM. Web Animations -------------- - Reviewed the recent updates and changes to Web Animations. - RESOLVED: Allow both events and promises in Web Animations. ===== FULL MINUTES BELOW ====== scribe: Nikos Transitions =========== Spec Status ----------- dbaron: There have been some relatively large edits since the WD - but only stuff that implementors would care about, dbaron: such as canceling and interrupting transitions. dbaron: I think I'm ready to take the spec to a new new process CR. dbaron: There's a bunch of issues in bugzilla. dbaron: I made some minor edits and there's a few we should talk about. dbaron: Anything that's a new feature is marked to defer to level 2. dbaron: There are a few that are about animating specific value types dbaron: like images and gradients. dbaron: Those should be deferred to CSS images. Transition Rules Defined for z-index:auto ----------------------------------------- dbaron: One question is whether there should be transition rules defined for z-index:auto. <dbaron> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16265 dbaron: Apparently testing showed that a bunch of engines do transitions between z-index:auto and numbers. dbaron: This may or may not just be a bug related to treating the value as zero. dbaron: The behavior that was observed was that if there was a transition between auto and number there was interpolation as if it were between zero and a number dbaron: and a jump at the end/ dbaron: Apparently zero to auto jumps were at both ends. dbaron: Do people think we should have special transition rules for z-index:auto? TabAtkins: I'd prefer not, I don't see how to do it properly. dbaron: A special rule would mean that any intermediate interpolation that was not 100% value or the other would treat auto as zero. dino: It looks to me like it's a bug. dino: What would you do otherwise? dbaron: Current behavior says if one value is auto you can't interpolate. dino: I think it's just a bug that webkit should fix. dino: We don't check that it's auto. <smfr> that might have compat risk for webkit but we should fix it (maybe with the non-prefixed transition, dino) RESOLVED: Leave z-index as is. dbaron: A few of the issues are a mix of feature requests for new things or things we've fixed. dbaron: So I'm inclined not to look at them. dbaron: If someone wants to help? Specifying when Computed Values Change --------------------------------------- dbaron: The one other issue filed is for more constraints specifying when computed values change dbaron: e.g. when transitions start. dbaron: I've avoided specifying too much there. dbaron: I don't want to make this a spec for the browser refresh cycle dbaron: and would like to leave room for optimization. dbaron: There was a statement that it was specifically not specified. dbaron: I realized I could specify it in a more useful way by saying the spec does not define when computed values change but if you do something with the computed value then the computed value has to have changed. dbaron: I wrote prose this morning. dbaron: So there is a definition that leads to useful results dbaron: and doesn't allow implementation to be conformant without doing anything. Florian: The intent sounds useful. Publishing CR ------------- dbaron: The big changes in this draft are mostly stuff we've discussed before. dbaron: More precise definition of canceling and interrupting running transitions dbaron: and the things we discussed in Paris about the details of interactions. dbaron: I haven't gotten a huge amount of feedback. dbaron: Given the number of implementations I think we should go to CR dbaron: and we'll get feedback from implementors. RESOLVED: CSS transitions can go to CR Florian: you're not currently in LC? dbaron: this is the new process dbaron: so we can go straight to Cr. CSS-Transforms: Specifying Decomposition of Scale =================================================== <stakagi> https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Specifying_decomposition_of_scale stakagi: I've prepared a wiki page. stakagi: I'd like to specify decomposition of scale. stakagi: The use case of scale are non scaling objects, and level of detail. stakagi: This scale is not scaleX or scaleY. stakagi: Non-scaling objects are a part of vector graphics stakagi: of SVG 2. stakagi: The SVG working group decided to put non scaling object functionality in SVG 2. stakagi: You can see a polyfill in the link on the wiki page. stakagi: And level of detail also determines standardization of functionality. stakagi: There is a video to demonstrate this. stakagi: The scale value decomposed from the transform matrix is required for each function stakagi: and such a scale value should be one scalar value stakagi: which is always meaningful on all the affine transformation involving skew. stakagi: The chapters on decomposing 2d and 3d matrices for scaling are dependent on specific axis. stakagi: I'd like to specify a method that does not depend on a specific axis. stakagi: I would like to introduce this into that chapter. stakagi: Each scale is based on the determinant of the matrix: stakagi: 2d decomposition is sqrt of determinant. stakagi: 3d is cube root. stakagi: Decomposition of scale can be calculated based on these scale. birtles: The specific proposal is to add an extra definition to CSS transforms birtles: of a scalar value for scale. birtles: Takagi-san has prepared a polyfill. In this he compares the definitions that are axis dependent with this version. birtles: If you skew the shape you can see that the area of the shape changes dramatically, birtles: but if you use the scalar value you can avoid this. heycam: We already have transform ref in the SVG spec heycam: which undoes all transforms from one space to another. heycam: Never mind. <ChrisLilley> http://www.w3.org/Graphics/ScalableReq ChrisLilley: This is obviously correct - this is something we've needed. ChrisLilley: We've achieved all requirements except level of detail. ChrisLilley: We're talking about extreme zoom. ChrisLilley: We need level of detail and it needs to work regardless of transformations. ChrisLilley: I support this. birtles: The proposal is to add this definition of scale to the part of CSS transforms that defines decomposition of matrices. birtles: Not necessarily to use in CSS transforms, but able to be referenced. birtles: I don't think it requires behavior of spec to change. birtles: This seemed like the most appropriate place to define it. krit: Decomposition has multiple steps. birtles: This would be another definition alongside the method that obtains a vector, that returns a scaler, birtles: it doesn't replace the current definition. birtles: We could possibly also add to the interpolation section. And in recomposition we can say multiply by these values. dino: You'd never be able to interpolate between the two values. heycam: Are you saying existing definitions could be simplified by referencing this new definition? birtles: I don't think that's the suggestion. dino: So in non scaling stroke part of SVG we can say that when you change zoom levels you should unscale by this decomposed value dino: and if you animate you should animate between these values. heycam: Going back to broader level of zoom media queries: heycam: A couple of years ago Ted was going to investigate different zoom use cases. heycam: Do you know if anything came of that? dino: I don't know. Florian: With zoom media queries we want to be really careful. Florian: Some things you don't want to expose Florian: e.g. pinch zoom. heycam: I think to solve the use cases we may need a switch to control what pinch zoom does. birtles: We talked about that but Takagi-san hasn't had a chance to come up with a proposal. dino: This is only really going to have an impact if people are scaling with a different amount on different axis. birtles: That's right. dino: How many people skew? heycam: I think Takagi-san recognized that in most cases it doesn't matter, heycam: but we should provide the definition for cases when it does matter. birtles: There's a formula in the wiki. krit: We'd be putting it into the transform spec without any context. krit: Does it need testing? heycam: Just review it to make sure it's ok heycam: then when another spec depends on it test that. stakagi: We might use it in SVG 2 and then we can test it there. heycam: krit, as editor how do you feel about it? krit: I need to look at the formula. krit: The idea seems ok. dino: It's important we specify the exact value for non scaling stroke so all implementations are the same - I think that's enough reason to accept this. heycam: The question is where should it live. krit: Best thing to do is to propose prose we can put into the spec krit: as long as there's no requirement to test it. stakagi: I will send a pull request. RESOLVED: Include Takagi-san's definition of linear scale in CSS transforms. ACTION: stakagi to propose specification text for new scalar value for CSS transforms <trackbot> Created ACTION-91 krit: Can I publish a new wd? last one was a long time ago <ChrisLilley> How about putting that recently agreed change in there first? RESOLVED: Publish new WD of CSS transforms with Takagi-san's changes. krit: Back to transforms WD - Simon added new preserve 3d stuff. Do we need agreement on it or can we talk about it after publication? dino: Is it ok to publish the WD with this section in it even though we may need to discuss it further? roc: Did we get any specific feedback from MS? krit: There were competing proposals. roc: There was just one minor issue I brought up. krit: I think the spec has an issue noting that so it should be ok to publish a WD. Web Animations ============== <birtles> http://people.mozilla.org/~bbirtles/pres/201502%20fxtf%20web-anim%20update/ [birtles presents] birtles: Want to give an update and ask some questions. Status Update ------------- birtles: This started to ship in little pieces. birtles: Chrome and Firefox have started at opposite ends of the API. birtles: and Firefox has some dev tools. birtles: We've published two WDs so far and another to come soon. birtles: This diagram (slide 2) shows moving pieces. birtles: There's been some simplification. birtles: We had motion path but that's been removed. birtles: There's now a motion path module birtles: created by krit. birtles: Recently we also deferred grouping to a subsequent level. birtles: it's useful but not critical. birtles: Diagram is now simpler - and I'd like to make it simpler still. birtles: I would like to merge Animation and Keyframe Effect. birtles: Animations are the dynamic part birtles: Keyframe Effect is static. birtles: This isn't in the spec yet. birtles: There's some concern that this may make Keyframe Effect objects less shareable birtles: but this is the model I'm proposing. birtles: It also makes the naming more straight forward. birtles: A lot of people found Players confusing. birtles: That's an update on where the spec is at now. Naming ------ krit: Is there a different name for Keyframe Effect? Anything shorter? shane: We had Player and it was too generic - is Animation too generic? birtles: I don't think so. birtles: We already have the term. dino: No fear of clobbering third party library that uses Animation? shane: That's something we need to do a little research on. dino: What other effects do you have? birtles: Only Keyframe Effects. birtles: Level 2 will have Group Effects and Sequence Effects. birtles: Still considering what to do with Custom Effects. krit: How do you set up a Keyframe Effect? birtles: New KeyframeEffect. shane: Also element.animate heycam: I would find Group Effect a bit confusing. heycam: The effect doesn't seem like the right word there - don't have suggestions. dino: Could be concurrent effect? shane: I find the name good - you're grouping a set of effects. heycam: That should be an effects group then. birtles: Distinction is it's the static definition, birtles: it's attached to an animation which is the dynamic part ChrisLilley: Shouldn't it be grouped effect then? birtles: Other APIs use 'set'. birtles: We can think about names some more. birtles: Other question I had - easing, iterations, fill. We chose these names because they're short to type. But it does introduce the problem that they're very different to the terms CSS animation uses. birtles: Is it better to line up with CSS or keep short? birtles: Two votes for keeping it short. ChrisLilley: If it aligns with CSS it has to be exactly the same thing. TabAtkins: It is. shane: Easing is much more of an industry standard than timing function. ChrisLilley: Fill on the other hand I've only ever seen in the context of SMIL. krit: I've seen it used a lot in JS libraries. ChrisLilley: Iterations over animation-iteration-count is good. ChrisLilley: Could you put an issue in the spec saying calling out to script for easing will be possible in the future? dino: We shouldn't really announce features. ChrisLilley: True - but good to explain why it's not there. Events vs Promises ------------------ birtles: Couple of other questions. <shane> https://docs.google.com/document/d/1f-KxMJwQ3f3OXSMvY-uQjpsy788BfyHlW9VoUWFvWQ4/edit#heading=h.b601rl56wy2f shane: First events and promises. shane: We switched from events to promises. shane: Only used in two scenarios. shane: Turns out that in different scenarios either events or promises can be useful. shane: In Firefox OS they've been doing things where you set up a transition to move between states of the UI shane: and key on the end. shane: All sorts of reasons why that won't trigger. shane: So it's difficult to build a reliable system on top of that shane: but with a promise you're guaranteed it will resolve or reject. shane: Much easier to be reliable. shane: So a strong use case for promises. shane: But promises can be the wrong tool as well shane: e.g. if you have an event you want to reuse you can call play.play and when it gets to the end it will clean up after itself. shane: If you use promises every time you call play you need to set up the promise. shane: Promises are one shot. shane: So in this case events are cleaner and easier than promises. shane: So could we have both? heycam: As long as you make sure that we have a consistent pattern in the order they are resolved and dispatched. TabAtkins: I don't have an order specified so we should think about that. dino: One of the best things about events is you can pass an object in to a listener. RESOLVED: Allow both events and promises in Web Animations Preserving the animation end state ---------------------------------- shane: The other thing I wanted to talk about: shane: You've got an animation that's filling forward, shane: can't change the value of the property that is animated. shane: That's probably the single most complained-about thing. shane: People ask why can't I change the animated value later - they try to do so in the dev tools and it doesn't allow them to. shane: The other problem is that we can't clean up because animations may be deleted and we have to fall back shane: so memory cost in some situations can be expensive . shane: Finally, if you want to cancel the animation - everything works ok first time, but if you start and cancel again you jump to the end state because you haven't cleaned up the previous one. heycam: Would it be a layering violation if those values meant fill unless there is another animation on top of me? shane: I'd like to be able to say that fill only applies until there is a style change. shane: If you have a fill and you want it to transition to a new value, if you set a transition and you set a new value then it should interrupt when you set the new value. dbaron: What counts as a style change? shane: Same as transitions. dbaron: So any change to that property on that element. dbaron: So this is different to CSS transitions? shane: Yes, so can we do this? Would it break the web? dbaron: Yes, it would. <dbaron> (Dean and Greg also said yes at the same time) shane: OK so it would be a separate thing, then. dbaron: It seems to be like one of the use cases for fill is I want this effect to happen where it starts somewhere and animates in some way and when animation finishes it stays there. ChrisLilley: Wanting it to stay where it is is a good result, ChrisLilley: but there's two ways to do that. ChrisLilley: One is to have a keyword that changes dom with final value. ChrisLilley: The other is to have an animation engine running that keeps the value there. dbaron: I'm worried about things where other things change the computed value. dbaron: Never mind. heycam: Once you get to the point where you're filling you want to have another mechanism for setting the fill value, heycam: where is that mechanism? dino: Why doesn't it become another keyword to fill? dino: that is an end event handler that sets the value. shane: This is the simpler behavior that will avoid programming errors so it should be the default. heycam: Regardless how you control it, not sure what the mechanism is for setting the value. shane: In our implementation we have an animation stack where we apply all the style rules. shane: Once we've applied the static styles we apply the animated styles on top - to override - shane: so that's where strongly held value is. shane: Animations with fill don't say they need to be updated every frame. shane: Transitions work a little differently. shane: This was the value I was transitioning to and the new value - if they're different we can stop. heycam: I was thinking maybe it would be something like - for every element there's some level in the cascade heycam: with properties that can be set or not heycam: and when animation gets to fill but not strongly, it sets that value in the cascade heycam: which is beneath the animations. heycam: What does setting the value mean .style.something = ? shane: Yes. heycam: I'm a little worried - how transitions trigger is difficult to get a handle on. shane: If transitions didn't have similar behavior I probably wouldn't want to go down this path. shane: Once you're using web animations under the hood, transitions and animations should be the same thing. shane: I'd also welcome suggestions for other novel solutions. dbaron: It feels weird for a fill animation. dbaron: But it does feel there may be a short cut for setting the style to this and also run this animation dbaron: or run the animation and while doing so set the style value to this. shane: The issue is where to put that - you can't put it in the inline style. birtles: The idea that you're updating the specified style in the background would avoid any discontinuity of behavior when you reach the end of the animation as opposed to updating the style when the animation finishes. shane: The problem with setting a value in the background is that there's no sensible place to set it. dino: So your proposal is to still run the fill animation. dino: It's just implicitly cancellable by any change dino: which is new behavior. shane: Yes. dino: I'd like to think about this. dino: I can see the need. shane: I just wanted to get a sense whether it was worth considering shane: and that seems to be the case. birtles: We've had requests in SVG to have animations that update the DOM dino: It's a bit more obvious if it comes from an api rather than SMIL. dino: Maybe it's that you would always set via animations. So take the result of the last animation rather than having a fill. dino: Everything could be an animation. cyril: We had a related issue when converting flash to SVG animations. cyril: We had animations per layer in the flash display list. cyril: Wanted to get rid of the old animations in previous frames. cyril: There was no way to signal. cyril: In SMIL we could use an attribute something like restart=never cyril: as an indicator that you could do garbage collection. translate, rotate, scale properties ----------------------------------- shane: We have one more set of things to talk about. TabAtkins: Some time ago Shane and I proposed adding to the family of transform properties a translate, rotate and scale property TabAtkins: that get slotted into the use translate list at the end. TabAtkins: Some were hostile, some liked it. TabAtkins: I think we should revisit this. TabAtkins: We have more precedent with motion path TabAtkins: which exists as a property and a function. TabAtkins: That's for good reason - and those same reasons apply here. shane: Jack Doyle's selling point is it can independently animate rotate, scale and translate shane: a lot of his customers find it useful. heycam: I worry it works well for separate translate and rotates. heycam: as soon as you have something that doesn't decompose into at most these three types heycam: it breaks down. heycam: So I'd prefer to see some mechanism that allows you to combine the values somehow. shane: For the simple case you're requiring people have knowledge of the ordering of transforms. heycam: You have fixed order. TabAtkins: There is a single correct order if you want them to act independently, TabAtkins: and it's not trivial. shane: You can define that rigorously. dino: right to some people dino: it's not what everyone wants. shane: We force people to think in terms of the scene shane: So it makes sense to define it in a particular way. birtles: We've got some pretty strong requests for this in the animation community. dino: You can still do it - it's just a little cumbersome with additive animation. shane: You can't. shane: With custom properties maybe. shane: With the web animations api I mean. dino: You can't write an animation that independently animates translation, scale and rotation? birtles: You can do it. birtles: It's hard. dino: At the moment in CSS you do it with nested elements. shane: I'll get back to you. [shane gives an example that requires knowing how to decompose matrices] TabAtkins: Is the argument all about whether you can tween in web animations? dino: I don't think so - if we do add these other properties, what's the fall back strategy? dino: If I add these properties and also add transform because I want it to work in other browsers. dino: You have properties that combine in a particular order. TabAtkins: There's a lot of layout features that also work like this - flexbox for example. TabAtkins: You can't polyfill, you just have to wait for support. <birtles> For reference, GreenSock's description of independent animation of transform components is described at https://greensock.com/why-gsap/ under "Scale, rotate, skew, and move without the headaches" <birtles> demo at: http://codepen.io/GreenSock/full/kingu/ <birtles> also, for reference, this request comes up a lot: https://twitter.com/rachelnabors/status/518773879117197313 birtles: From a use case point of view I think it's really useful. dino: This is really a change to the transform spec, not animations. dbaron: I guess I'm ok with it if there's a rule for how they all compose. dino: So if you did translate(10,10) transform="scale(2)" then it's not round tripable dbaron: It might be confusing to people if they do transition: transform dbaron: That won't transition if they change translate. TabAtkins: Does that confuse people if they transition on transform and then change the perspective property it does not transition? shane: I think this is one of those situations where you have a simple and a complex world and let people opt into the complex world if they want. shane: The case for using both is a programming error and should be avoided. shane: So we want to add a simple model. dino: My main issue is I'm not sure it's worth it. dino: I understand the issues people are hitting. shane: If it's just for the static cases I would agree, but there's a powerful animation argument. It's very hard to do some things without this. TabAtkins: I hear more conclusions that it would be worth having so we should take another look at it. TabAtkins: Ideally I'd like to put it in and see if we get objections. dmitry: What if I want to animate rotation and rotation? TabAtkins: Use transform. shane: If we put this in the spec and it turns out there's other ways of doing it we'll take it out. shane: So can we put it in the spec? shane: In CSS transforms? dbaron: In level 2? shane: I'd be happy with that. RESOLVED: We will add translate, rotate and scale properties in CSS transforms level 2
Received on Friday, 20 March 2015 06:42:25 UTC