- 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