Re: [csswg-drafts] [css-easing-2] Complex easing/timing functions (#229)

The CSS Working Group just discussed `easing timing functions`.

<details><summary>The full IRC log of that discussion</summary>
&lt;fremy> Topic:  easing timing functions<br>
&lt;astearns> github: https://github.com/w3c/csswg-drafts/issues/229<br>
&lt;fremy> AmeliaBR: this is another old issue, that had a lot of discussion for a while, but every so often somebody finds it again, and revives the issue<br>
&lt;fremy> AmeliaBR: the issue is that all the easing functions are only continuous curves<br>
&lt;fremy> AmeliaBR: you can use strong coefficients to create a slight overshoot, but that doesn't allow rebounds<br>
&lt;fremy> AmeliaBR: so the request is to have more complex functions<br>
&lt;fremy> AmeliaBR: most animation software have ways to create those functions, but now they can't be exported to css<br>
&lt;hober> q+<br>
&lt;fremy> AmeliaBR: and they have to be exported to huge keyframe sequences which are difficult to maintain and understand<br>
&lt;hober> https://lists.w3.org/Archives/Public/www-style/2016Jun/0181.html<br>
&lt;astearns> https://github.com/w3c/csswg-drafts/issues/229#issuecomment-492367598<br>
&lt;fremy> AmeliaBR: there is a proposal to use cubic bezier but it allows too much for what we want<br>
&lt;fremy> AmeliaBR: there is also a more recent proposal, and I happen to like it<br>
&lt;dbaron> cubic beziers as defined currently are well-defined functions since we give only 2 of the 4 control points and the x values are constrained to [0,1]<br>
&lt;fremy> AmeliaBR: but there is also the option of using the cubic bezier syntax and let the browser fix that up if the function isn't pure<br>
&lt;astearns> ack hober<br>
&lt;fremy> AmeliaBR: so our first question, what should we do first, get a great syntax or extend the type of syntax we have now<br>
&lt;hober> spring(mass stiffness damping initialVelocity)<br>
&lt;fremy> hober: we think this is a good idea<br>
&lt;fremy> hober: we like this syntax, and we are all for it<br>
&lt;fremy> astearns: any other comment?<br>
&lt;fremy> heycam: what's the unit that this proposal used?<br>
&lt;fremy> heycam: css values should have the answer<br>
&lt;flackr> q+<br>
&lt;fremy> astearns: dbaron pointed out on irc that cubic-bezier can work as functions<br>
&lt;astearns> ack flackr<br>
&lt;fremy> AmeliaBR: yes because we remove some parameters, but as you try to add expressivity, it's difficult to maintain that<br>
&lt;majidvp> q+<br>
&lt;astearns> ack majidvp<br>
&lt;fremy> majidvp: one thing I like about this idea, it's possible to approximate a spring using the proposal, which is great because other we have to specify ourselves all the types of bounds we want, but authors will still want more<br>
&lt;hober> s/we think this is a good idea/dean proposed a spring timing function a few years ago. we're supportive of having such a thing./<br>
&lt;fremy> AmeliaBR: yes, if we have a generic expression syntax that handles many things, we can get spring to be an alias to that<br>
&lt;hober> s/we like this syntax, and we are all for it//<br>
&lt;argyle> 😍<br>
&lt;fremy> astearns: I don't see much desire to discuss the precise syntax, but there is some interest<br>
&lt;fremy> fantasai: should we add somebody to edit the spec?<br>
&lt;fremy> astearns: but I don't see enough interest to add this to a spec<br>
&lt;fremy> myles_: AmeliaBR what are you trying to achieve here?<br>
&lt;fremy> AmeliaBR: get agreement that a generic mechanism would be great to add to easing-2<br>
&lt;fremy> myles_: my problem with the generic approach, is that the end result is just complex math, and doesn't explain what the end result should look like<br>
&lt;fremy> myles_: which is why I prefer `spring` because it has clear intent<br>
&lt;fremy> myles_: also, as designer, I think I would draw what I want in a software, as a piece-wise function<br>
&lt;astearns> ack dbaron<br>
&lt;fremy> myles_: and that is not easy to express as a cubic-bezier<br>
&lt;fremy> dbaron: I think adding new things in that space is reasonable, but I think I would want to weight the implementation cost, but in general I'm in favor of adding expessivity in the spec here<br>
&lt;fremy> AmeliaBR: the last proposal has very nice pictures, and seem well accepted<br>
&lt;dbaron> dbaron: nice pictures and few/no equations<br>
&lt;fremy> astearns: one way to make progress is to find the contributor that submitted the various comments, and convince that person to collect them in a spec in wicg<br>
&lt;fremy> AmeliaBR: I'm willing to try to get that to happen, if there are other people interested they are welcome to join me<br>
&lt;majidvp> q+<br>
&lt;fremy> flackr: I'm interested in the space as well, but didn't evaluate<br>
&lt;fremy> flackr: the current proposal<br>
&lt;astearns> ack majidvp<br>
&lt;fremy> flackr: but my attention will be about ease of write, and ease of parse<br>
&lt;fremy> fantasai: and ease-of-read as well<br>
&lt;fremy> flackr: yes<br>
&lt;fremy> majidvp: i would also want to note that if you have an houdini approach, we can allow any js function, then sample it<br>
&lt;fremy> majidvp: previously houdini was a big leap in the space<br>
&lt;fremy> majidvp: but right now, we have a lot of things ready, and this would be easily doable<br>
&lt;fremy> hober: I'm weary of putting off very desirable features to js<br>
&lt;fremy> majidvp: I'm not saying we shouldn't do a declarative approach, but I don't see why both can't be pursued at the same time<br>
&lt;fremy> hober: sure<br>
&lt;fremy> myles_: we are fine with a houdini approach<br>
&lt;fremy> myles_: but that shouldn't prevent us from delivering features that are directly relevant to authors<br>
&lt;hober> s/to js/until houdini is ready/<br>
&lt;myles_> s/we are fine with a houdini approach/the presence of houdini doesn't allow us to stop making good features for our users/<br>
&lt;majidvp> I agree with that sentiment :)<br>
&lt;fremy> AmeliaBR: ok, so the conclusion is that we are going to try to gather a community to make this happen, thanks everyone for the feedback<br>
&lt;fremy> &lt;br /> (after which we would talk about motion-blur)<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/229#issuecomment-499633731 using your GitHub account

Received on Thursday, 6 June 2019 19:25:41 UTC