[CSSWG] Minutes Sydney F2F 2015-02-11 Part III: Transitions, CSS Transforms, Web Animations


  - RESOLVED: No special treatment of 'z-index: auto'; it's not
              possible to transition between auto and other z-indices.
  - RESOLVED: CSS transitions can go to CR.

CSS Transforms

  - RESOLVED: Include Takagi-san's definition of linear scale in CSS
              transforms (details available here:
  - RESOLVED: Publish new WD of CSS transforms with Takagi-san's
  - 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.


  scribe: Nikos


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
  dbaron: Anything that's a new feature is marked to defer to level

  dbaron: There are a few that are about animating specific value
  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
  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
  dbaron: and would like to leave room for optimization.
  dbaron: There was a statement that it was specifically not
  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
  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
  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

  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
  ChrisLilley: We've achieved all requirements except level of
  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
  birtles: Not necessarily to use in CSS transforms, but able to be
  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
  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
  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
  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

  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

  krit: Back to transforms WD - Simon added new preserve 3d stuff.
        Do we need agreement on it or can we talk about it after
  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
  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

  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.


  krit: Is there a different name for Keyframe Effect? Anything
  shane: We had Player and it was too generic - is Animation too
  birtles: I don't think so.
  birtles: We already have the term.
  dino: No fear of clobbering third party library that uses
  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
  TabAtkins: It is.
  shane: Easing is much more of an industry standard than timing
  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
  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
  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
  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
  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
  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
  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
  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
  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
  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
  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

  TabAtkins: Is the argument all about whether you can tween in web
  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:

  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
  dbaron: I guess I'm ok with it if there's a rule for how they all
  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:
  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
  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